AudioCodes Mediant 800B - Page 661

Version 7.2 661 Mediant 800B Gateway & E-SBC
User's Manual 29. SBC Overview
the original value with itself in the incoming message.
In contrast, when the device operates in Stateful Proxy mode, the device by default
forwards SIP messages transparently (unchanged) between SIP endpoints (from inbound
to outbound legs). The device retains the SIP dialog identifiers and topology headers
received in the incoming message and sends them as is in the outgoing message. The
device handles the above mentioned headers transparently (i.e., they remain unchanged)
or according to configuration (enabling partial transparency), and only adds itself as the
top-most Via header and optionally, to the Record-Route list. To configure the handling of
these headers for partial transparency, use the following IP Profile parameters (see
'Configuring IP Profiles' on page 436):

IpProfile_SBCRemoteRepresentationMode: Contact and Record-Route headers

IpProfile_SBCKeepVIAHeaders: Via headers

IpProfile_SBCKeepUserAgentHeader: User-Agent headers

IpProfile_SBCKeepRoutingHeaders: Record-Route headers

IpProfile_SBCRemoteMultipleEarlyDialogs: To-header tags
Thus, the Stateful Proxy mode provides full SIP transparency (no topology hiding) or
asymmetric topology hiding. Below is an example of a SIP dialog-initiating request when
operating in Stateful Proxy mode for full transparency, showing all the incoming SIP
headers retained in the outgoing INVITE message.
Figure 29-1: Example of SIP Message Handling in Stateful Proxy Mode
Some of the reasons for implementing Stateful Proxy mode include:

B2BUA typically hides certain SIP headers for topology hiding. In specific setups,
some SIP servers require the inclusion of these headers to know the history of the SIP
request. In such setups, the requirement may be asymmetric topology hiding, whereby
SIP traffic toward the SIP server must expose these headers whereas SIP traffic
toward the users must not expose these headers.

B2BUA changes the call identifiers between the inbound and outbound SBC legs and
therefore, call parties may indicate call identifiers that are not relayed to the other leg.
Some SIP functionalities are achieved by conveying the SIP call identifiers either in
SIP specific headers (e.g., Replaces) or in the message bodies (e.g. Dialog Info in an
XML body).

In some setups, the SIP client authenticates using a hash that is performed on one or