5.7. SIP Mediation

SIP Mediation features of the ABC SBC allow administrators to introduce massive changes to the signaling protocol. This is often necessiated by devices with imperfect SIP support, differing practices such as dialing plans between peering providers, or need to implement network-based services such as Private Asserted Identity (RFC 3325).

The actual mediation rules are placed in inbound and outbound rules. The inbound rules are used to modify incoming traffic coming from a Realm or a Call Agent to comply to local policies. For example, the inbound rules may transform telephone numbers from a local PBX’s dialling plan to the global E.164 standard. All subsequent actions already work with modified SIP messages. The outbound rules are used to modify outgoing traffic to a form that the receiving Call Agent can or shall process. For example the outbound rules can remove all but low-bandwidth codecs for the target known to be on a low-speed link.

It needs to be understood that mediation is a double-edged sword: massive changes to the signaling protocol can, if not configured properly, cause substantial harm to interoperability. If the ABC SBC encounters, that a SIP message modified by mediation rules breaks standard too far (such as if it generates an empty header-field), it discontinues processing of the message and sends a 500 response back. Still many changes may be syntactically legitimate, remain undetected and result in impaired interoperability.

This section discusses mediation of the signaling protocol, SIP. Mediation of media, that includes codec negotiation and transcoding, is documented in the section Media Handling.

5.7.1. Why is SIP Mediation Needed?

There are multifold root causes why SIP devices have often troubles communicating with each other. There are different standardization groups working on SIP. Different developers often interpret the same specifications differently. Operators deploy different operational and naming practices.

The ABC SBC has the capability to overcome some of these interoperability problems by manipulating the content of SIP messages so that they better fit the expectations of the receiving side. One can distinguish between several frequent interoperability issues: compatibility between various SIP protocol extensions, dealing with deviations from the specification and best current practices caused by non-compliant devices and operating procedures, and incompatibility between different transport protocols used for conveying SIP signaling.

SIP Standard Extensions:

There are various flavors of the SIP protocol. Even the basic SIP IETF standard is extended by tens of accompanying specifications, some of them are deployed, some of them not. Several other standardization bodies have chosen to add even more extensions specific to their use of SIP. In the fixed environment, the TISPAN specifications <http://www.etsi.org/tispan/> are used. In the mobile network environment the 3GPP IMS specifications <http://www.3gpp.org/> are the most favoured. SIP-I <http://www.itu.int/rec/T-REC-Q.1912.5-200403-I/en> is proposed for trunking scenarios in which SIP is used as the signalling protocol used to connect SS7 based networks over an IP core network.

The differences between the SIP specifications from IMS, IETF and TISPAN are mainly restricted to the addition of certain headers, authentication mechanisms and usage of certain SIP extensions such as NOTIFY/SUBSCRIBE or certain XML body formats.

In the context of interoperability of SIP flavours, the ABC SBC can provide the following services:

  • Stateless SIP header manipulation: The ABC SBC can be configured to remove certain headers and add others. This way, The ABC SBC can for example delete headers that are useful in an IMS or TISPAN but not in an IETF SIP environment.
  • Message blocking: Certain SIP messages might be useful in one network as they provide a certain service. However, if this service is not provided across the interconnection points then exchanging them across the networks does not make sense. SBCs can be configured to reject certain messages such as NOTIFY if presence services are not provided across the network for example.

Deviations from the SIP Standard and Best Practices:

The experience from various interoperability events shows that different vendors interpret the SIP specifications slightly differently. Especially parts that are specified with the strength of “SHOULD” or “MAY” are often implemented as a “MUST” or ignored completely. This makes the communication between two components from different vendors sometimes impossible. Sometimes even if the SIP equipment implements the standard correctly, operators practices for deploying SIP differ to the extent that the protocol needs to be fixed.

The ABC SBC can be configured to overcome some of these issues and to fix certain issues that cause these interoperability problems by offering the following features:

  • Existence of certain headers: Some SIP components expect to see certain SIP headers with certain information, for example a Route header pointing to them. Others might not bother to add this header. The ABC SBC can be configured to take these special interpretations of the implementers into account before forwarding a request and add or remove problematic headers.
  • Location of information: Some SIP components expect to see their address in the Request-URI whereas others want to see it in the Route header or both. This might not always be how the location information is included in the SIP request especially if a request was redirected from one component to another.
  • Tags and additional information: Again some SIP components might expect to see certain tags and parameters attached to certain headers such as rport with a Via header whereas other SIP components might not add them.

SIP Transport:

SIP can be transported over UDP, TCP and TLS. The capabilities of different SIP implementations might vary with this regard. That is, some components could support UDP but not TCP and others prefer to use TLS. Therefore, the ABC SBC can be used to convert the transport protocol used by the source to the transport protocol preferred by the destination.

5.7.2. Request-URI Modifications

The most common manipulation is that of request-URI. Request URI describes who should receive the SIP request. It may include an E.164 telephone number (like sip:+1-404-1234-567@pbx.com), a PBX number (sip:8567@pbx.com) or be formed as an email-like address (sip:amadeus@mozart.at). A typical reason for changing the request URI is normalisation of different dialling plans. As an example you may translate a local extension number (768) for a PBX with prefix (+1-404-1234) into a globally routable E.164-based URI sip:+1-404-1234-567@national-gateways.com. You can use several types of modifications to the request-URI, all of them are applied only to the first session’s request. The most important request-URI actions are the following:

  • Strip RURI user:  strips the specified number of leading characters from the user part of request URI. For example strip-RURI-user(1) applied to the PBX URI 8567@pbx.com yields the extension sip:567@pbx.com without the local “8” prefix. The action is applied as many times as it is callled.
  • Prefix RURI user:  inserts a prefix to the user part of request URI. For example, prefix-URI(“+1-404-1234-”) applied to the URI from the previous step yields sip:+1-404-1234-567@pbx.com. The result is accumulated if the action is applied several times.
  • Append to RURI user:  appends a suffix to the user part of request URI. The parameter takes suffix value. It may include replacement expressions. The result is accumulated if the action is applied several times.
  • set RURI:  entirely replaces the request URI with a new value.

Also note that the resulting URI not only describes the recipient, but its host part is used to determine the next hop IP address if a route is used with the Route via R-URI option.

It is also worthwhile mentioning that URIs often represent additional services a caller gets. For example if a caller prefixes number of an O2 subscriber in Germany with 33, his call will be directly routed to the recipient’s voicemail. However administrators would be ill advised to overload request URI with more than routing functionality. An infamous example is using a plain-text password as phone number prefix for authentication. The fraudster Edwin Pena <http://www.fbi.gov/newark/press-releases/2010/nk020310a.htm> found that out, yielded more than 10 million minutes of VoIP service and in 2009 eventually two years in federal prison.

Several other mediation actions can process sub-parts of request-URI. They include:

  • Set RURI host

    • Replace host(:port) part of Request-URI with a new value specified in the GUI.
    • Parameters: new host or host:port
  • Set RURI parameter

    • Add or replace parameter of Request-URI.
    • Parameters: RURI parameter name, RURI parameter value
  • Set RURI user

    • Replace user part of Request-URI with a new value.
    • Parameters: new user part.
  • Set RURI user parameter

    • Add or replace parameter of user part of Request-URI.
    • Parameters: parameter name, parameter value.

5.7.3. Changing Identity

Identity of SIP session participants is also described in many other SIP header fields that sometimes need to be changed.

Every SIP request must include URIs of session initiator in the From header-field and URI of intended recipient in the To header field. The SIP standard has intended to use the From and To header field only as informational description of how a session was started . URI of the originator in the From header field has limitied identity value as the plain-text URI is not covered by a message integrity check and can be easily changed by elements in the SIP-path. Even a user client is quite free to put anything in the URI unless there is a client’s outbound SIP proxy enforcing specific address for a digest-verified caller.

The URI in To header-field may have little relation to the actual recipient of a SIP request as the actual next hop is stored in the request URI.

Notwithstanding how “light-weight” information From and To header fields convey, some operators deploy policies based on them. They may only accept requests with From and To URIs that comply to their local convention. There were even cases when To URI was used for routing. Therefore it is often useful to modify To and From header fields. These modification rules apply to the first request of a SIP dialog. From and To in all subsequent messages of a session are transformed transparently in compliance with the SIP protocol specification. The most important To and From changing actions are the following:

  • Set From / Set To :replaces the whole From/To header field with a new value, for example “Jasmine Blue” sip:jasmine@blue.com. Only “tags” in the From/To header-fields remain unchanged to guarantee unique identification of SIP dialogs.

  • Set From User / Set To User: replaces the user part of the From/To URI.

  • Set From Host / Set To host: replaces the host(:port) part of URI with a new value

  • Set From / To display name

    • Set only the display name of the From / To header.
    • Parameter: new display name.

Additionally, the SIP protocol is using digest authentication identity (RFC 2617) to verify who is initiating a request. If the digest identity of a request originator needs to be changed, the action UAC auth is used. It takes the following paramters needed for the authentication procedure: username, password and realm. A request forwarded downstream and challenged to authenticate by a downstream server is then resubmitted by the ABC SBC using these credentials. Substitution Expressions

SIP message modifications typically “glue” pieces of the original messages and intended changes. For example, a new To URI is to be formed using destination’s hostname (say “target-gw.com”) and telephone number in request URI (say “+1-404-1234-567”). The corresponding set-To action needs to access the telephone number in the original request. To address cases like this, the mediation parameters may refer to elements of the original message by so called Replacement expressions. These always begin with a $ character. In our example, the user part of the request URI is referred to as “$rU” and the action has the form:

Set To (“sip:$rU@targetgw.com”).

Other important replacement expressions are $fu for From URI, $tu for To URI, $si for source IP address, $H(headername) for value of a header field.

If you need to access some sub-parts of the original SIP message without an addressable name, simple substitution expression are not enough. Then regular expressions have to be used to select them. This is called „regexp backreferences. The backreference expressions refer to parts of SIP messages that were matched in rules’ conditions. For example, to access the protocol discriminator in a URI, you need to create a rule condition matching it using regular expression, and then refer to the matched expression. You would be forming a rule like this:


Figure 1: Example of a Condition Being Referred to by a Backreference Expression

the second condition’s first sub-part (i.e. matched by the expression in the first parenthesses) of the regular expression would identify the protocol discriminator and yield “sip” for SIP URIs. The expression would be formed as this


5.7.4. SIP Header Processing

URI adaptation shown in previous paragraphs is important for harmonisation or routing and identity representation between different SIP devices and administrative domains. Yet there are many other header fields conveying important information in need of adaptation. Worse than that, some of them are not even known at the time of writing this documentation. That’s because some of them may be proprietary – for example Sipura SIP phones add QoS reports to every BYE message they send. Some header fields may even be specified in recently published standard. Yet even then the ABC SBC can help – it can use general purpose text-processing methods thanks to SIP’s text-based nature. Particularly the following actions are available:

  • Remove Header: Remove-header removes all occurrences of a header-field identified by its case-insensitive name from all requests and responses in a session. Exceptions apply: mandatory header-fields are not removed: CallID, From, To, CSeq, Via, Route, Record-Route and Contact. If a header-field with compact name form occurs, both forms  must be removed explicitly. Newly added header-fields are not removed by this action.

  • Set Header Blacklist: is a convenience function removing multiple header fields by a single action. It takes comma-separated list of header-field names as parameter and achieves the same effect as if you used multiple occurrences of the Remove-Header action. Blacklists are applied one by one in the order in which they appeared in the rules and are executed after applying both A and C rules. Blacklists can be a nice short-cut for removing a header-field  which has both normal and compact name. For example, you may want to configure deletion of both forms of the Subject header field by using

  • Set Header Whitelist: is an even more aggressive convenience function for removing multiple header fields. If used, all but mandatory and whitelisted header fields are removed from all requests and responses belonging to a session. Tje action is applied after processing of both A and C rules completes.

  • Add Header: adds a new arbitrary header-field to a dialog-initiating request. This action only applies to the first request of a session. Its greatest power comes from the ability to craft complex header-fields using the substitution expressions. SIP Header Modification Examples

Let us show the power of these actions on an example. A real-world case is translation of identity between the pre-standard Remote-Party-ID header field, still used by some SIP equipment, and the standardised Asserted Identity, see RFC 3325. Both fulfil the same purpose, yet differ in their syntax which needs to be translated from one form into the other.

The pre-standard header-field looks like this

Remote-Party-Id: "Mr. X" <sip:+1-404-1234-000@sipsip.com>;privacy=full

The standard form looks like this

P-Asserted Identity: "Mr. X" <sip:+1-404-1234-000@sipsip.com>

The simplest way for translation is

  • finding out if there is an occurrence of Remote-Party-Id header-field by a rule with condition

    if Header(Remote-Party-Id) does not match RE ^$"
  • removing the header field by action

  • and eventually forming the newly crafted header field using the URI in the previous header-field by

    Add-Header(P-asserted-identity: $Hu(remote-party-id)"

Note that while this example mostly works, it ignores some parameter details for sake of brevity.

It is important to keep in mind that mediation changes have impact on subsequent SIP processing: replacement expressions and header-field tests in condition consider the changed value.

The following example rules change request URI and From URI.


Figure 2: Impact of Mediation Changes on Subsequenet Processing

Substitution expressions in the Add Header Action print the request URI and From URI in a troubleshooting header-field named x-after-change. Because they refer to the **current* value, the new URIs appear in the outgoing INVITE regardless what they included originally. Similarly, the header-field value condition that tests if the From URI has assumed the new value prints YES in another troubleshooting header-field name x-from-is-new:

INVITE sip:new@ruri.com SIP/2.0.
Via: SIP/2.0/UDP;branch=z9hG4bKtwvtoaKk;rport.
From: <sip:new@from.com>;tag=170A7805-533943A10009B434-D85F9700.
To: <sip:uritest@abcsbc.com>.
CSeq: 10 INVITE.
Call-ID: 77443978-533943A10009B47B-D85F9700.
User-Agent: Blink Lite 3.1.1 (MacOSX).
x-after-change: RDOT sip:new@ruri.com FU new@from.com.
x-from-is-new: YES.

5.7.5. Early Media, Ring Back Tone and Forking

In SIP, so called “early media” and “forking” are quite complex SIP features which make interoperability sometimes a challenge, especially when occuring together.

Early media appeared in the SIP protocol as a PSTN backwards-compatibility feature. In PSTN the difference between early media like “please wait your call is important to us” and the actual call is simple: the latter is charged for, the former is not. This is by the way the reason, why “early media” is sometimes humorously refered to as “late charging”. Early media appear often when the called party is a PSTN gateway. The same protocol vehicle is often also used to implement “ring back tone”. The protocol flow is rather simple: The callee sends a provisional response with a reply code equal to 180 or 183 including an SDP answer and starts sending RTP with the ring back tone to the caller. Usually, the caller User Agent only starts rendering the ring back tone to the user when this response is received. The protocol usage examples and details are well described in the RFC 3960.

Forking is a feature anchored in the SIP specification RFC 3261. It permits SIP proxy servers to forward one incoming requests to multiple different destinations. For example, one can setup this way all his phones to ring in parallel: soft-phone, hard-phone, smart-phone and even a PSTN phone behind a PSTN gateway. Forking can occur in parallel or in series. If serial forking is used, a forking proxy following best current practices sends a 181 inbetween. The “forked” INVITE requests may look almost identical but each of them always must have a unique “branch” identifier in the topmost Via header field.

Various unpredictable situations appear when forking and early media appears at the same time. For example two PSTN gateways send both early media to the caller. To deal with such situations the ABC SBC does only accept the first early media stream and discards the subsequently received ones.

The actions described in this Section help to customize the behaviour of the ABC SBC to some special cases.

The action Drop SDP from 1xx replies drops SDP payload from all listed 1xx SIP answers. The action takes as parameter a comma-separated list of reply codes. SDP payloads are dropped from all responses with any of these codes. This action is especially useful if specific replies should be handled, for example a locally generated ring back tone should be preferred to a ring back tone from the far end. Note that the RTP relay is not started if all provisional response are dropped, i.e. a provisional response needs to be processed for the RTP relay to be initialised, also for relaying early media.


Figure 3: Drop SDP from reply

Another action Drop early media drops the RTP packets of early media, that is until the call is established. Note that if early media shall be dropped from signaling entirely, the actions “Drop SDP from 1xx replies” in combination with “Translate reply code” 183->180 must be used.


Figure 4: Drop early media

Support serial-forking proxy: This action allows to reset early media when a downstream SIP proxy server indicates by a 181 reponse that
it has chosen to try some other destination for the call. By default, only the first early media arriving to the SBC is permitted, all other early media is dropped. This strict policy assures that downstream SIP forking cannot create multiple early media streams mutually interfering with each other. With this option, one can make an exception to the rule and permit early media coming later to override the previously established early dialog. It works safely as long as there is no parallel early media and 181 indicates that a later early media stream legitimately replaces the previous stream.

The following SIP flow-chart from Section 2.9 of RFC 5359 show a situation in which a SIP proxy generates a 181

Alice            Proxy         User B1             User B2
  |                |              |                   |
  |    INVITE F1   |              |                   |
  |--------------->|   INVITE F2  |                   |
  |(100 Trying) F3 |------------->|                   |
  |<---------------|180 Ringing F4|                   |
  | 180 Ringing F5 |<-------------|                   |
  |<---------------|              |                   |
  |                 Request Timeout                   |
  |                |              |                   |
  |                |   CANCEL F6  |                   |
  |                |------------->|                   |
  |                |   200 OK F7  |                   |
  |                |<-------------|                   |
  |                |     487 F8   |                   |
  |                |<-------------|                   |
  |                |     ACK F9   |                   |
  |                |------------->|                   |
  |(181 Call is Being Forwarded) F10                  |
  |<---------------|              |    INVITE F11     |
  |                |--------------------------------->|
  |                |              | 180 Ringing F12   |
  | 180 Ringing F13|<---------------------------------|
  |<---------------|              |      200 OK F14   |
  |                |<---------------------------------|
  |   200 OK F15   |              |                   |
  |<---------------|              |                   |
  |     ACK F16    |              |                   |
  |--------------->|              |     ACK F17       |
  |                |--------------------------------->|
  |               Both way RTP Established            |
  |    BYE F18     |              |                   |
  |--------------->|              |      BYE F19      |
  |                |--------------------------------->|
  |                |              |    200 OK F20     |
  |  200 OK F21    |<---------------------------------|
  |<---------------|              |                   |
  |                |              |                   |

The action Fork allows to add a new branch to a processed request and start forking. Multiple occurences of the action result in multiple branches of the request. The action takes only one parameter, the request URI of the forked request. The parameter can use replacement expressions, however if an invalid SIP URI is formed the call will fail.


Figure 5: Forking

5.7.6. Call transfers

Using the action Call transfer handling it can be configured how in-dialog REFER requests are handled in the ABC SBC. The configuration is per call leg, i.e. if used in inbound (A) rules REFER handling is set for the A leg, if used in outbound (C) rules it is set for the B leg.

Following methods of REFER handling can be used:

  • pass-through

    Pass REFER through the ABC SBC to the remote peer (default).

  • reject

    Reject the REFER request with a 403 Forbidden reply.

  • handle internally

    In case of an attended call transfer to another call established through the ABC SBC (REFER with Replaces in Refer-To pointing to a local call) the call legs are connected locally. Only offer-answer exchanges (re-INVITEs) that synchronize session description on both ends are generated.

    In case of an unattended call transfer (no Replaces in Refer-To) the ABC SBC generates a new INVITE to the requested destination. This INVITE can be handled in routing (B) rules and outbound (C) rules similarly to regular calls. For detection of such locally generated calls the condition Request source can be used.

    In case of an attended call transfer to a non-local call (Replaces in Refer-To refers to a non-existent call leg) the ABC SBC generates a new INVITE with Replaces to the requested destination. This INVITE can be handled the same way as an INVITE generated for an unattended call transfer mentioned above.


  • only in-dialog REFER requests are handled
  • attended call transfer is not possible with transparent call IDs

5.7.7. INVITE with Replaces handling

ABC SBC is able to handle INVITE with Replaces header locally, if the Replaces header points to a call established on the SBC.

The action Handle INVITE with Replaces header is used for this purpose - it activates local INVITE with Replaces handling.


  • INVITE with Replaces can not be handled when replacing call with transparent call IDs

5.7.8. Mapping Dialog-IDs in INVITEs with Replaces

If an INVITE with Replaces passes the ABC SBC, and the call to be replaced is also traversing the SBC, with transparent call IDs not enabled the Dialog Identifiers in the Replaces header refer to the call leg on the side before the SBC, but do not have a meaning after the SBC.

Using the Map Replaces header action, the dialog identifiers are replaced with the corresponding ones on the other side of the SBC so that the Replaces still is valid.

5.7.9. Other mediation actions

the ABC SBC supports various actions related to SIP processing:

  • Enable transparent dialog IDs

    • Use the same dialog identifiers (Call-ID, From-tag, To-tag) on both sides of a call (e.g., for the incoming and out going messages). If this action is not enabled, the FRAFOS ABC SBC changes dialog identifiers. Unchanged Call-ID may be a security concern because it may contain the caller’s IP address. However, transparent identifiers make troubleshooting and correlation of call legs much easier. Also, for call transfers using REFER with Replaces as used in call transfer scenarios to work through the SBC, transparent dialog IDs need to be enabled.
  • Forward Via-HFs

    • This option makes the SBC keep all Via headers while forwarding the request. This behaviour mimics what a proxy would do, especially in combination with the Enable transparent dialog IDs action (the only remaining difference to a proxy is the non-transparent Contact header field). Note that forwarding the Via headers exposes the IP addresses of entities on the incoming leg side of the request.
  • Translate reply code

    • Change SIP response code and reson for all SIP responses with a specific code. Note that changing responses between SIP reply classes may seriously break proper operation.
    • Parameters: SIP response code to change, SIP code and reason phrase to use for the reply sent out.
  • Allow unsolicited NOTIFYs

    • The ABC SBC keeps track of subscriptions and usually only lets NOTIFY messages through if a subscription for it has been created before (through a SUBSCRIBE or a REFER). This action tells the SBC to let pass NOTIFY messages even if no subscription has been created before.
  • Relay DTMF as AVT RTP packets (RFC4733/RFC2833)

    • relays DTMF tones as RTP avt-tones packets (RFC 4733/RFC 2833)
    • Parameters: none
  • Relay DTMF as SIP INFO
    • relays DTMF tones as proprietary SIP INFO payload
    • Parameters: none
  • Diversion to History-Info

    • converts SIP diversion header-field (RFC 5806) into the History-Info header-field (RFC 4244) using the guidelines set in RFC 6044.
    • Parameters: none
  • Set Max Forwards

    • sets the value of Max-Forwards header field in forwarded SIP requests to the configured value. This limits the number of hops a request can be forwarded until it is bounced back. It may make sense to set it to a lower value than RFC 3261 recommends (70). If this action is not used, the value in incoming request is decremented by one before forwarding.
    • Parameters: number of hops.
  • Set Content Type whitelists and Set Content Type blacklists

    • limits SIP content types to well known payload types (whitelists) or to all but specifically prohibited payload types (blacklists). Most VoIP SIP requests include the type of application/sdp.
    • Parameters: comma-separated list of content-types
  • Add dialog contact parameter

    • Allows to add a parameter to the contact URI generated by the SBC.
    • Parameters: The side of the call (caller/A leg, callee/B leg) can be specified, the parameter name and value.
  • Set Contact-HF parameter whitelists and Set Contact-HF parameter blacklists

    • defines which Contact HF parameters are forwarded through the ABC SBC . By default no parameters are forwarded. With whitelisting, only specified parameters are forwarded. With blacklisting, all but specified paramters are forwarded.
    • Parameters: comma-separated list of Contact parameter names
  • Forward Contact-HF parameters

    • makes sure all Contact HF parameters are forwarded as received in incoming request. If no action is used, no parameters are forwarded at all.
    • Parameters: none
  • Call transfer handling

    • The actions defines in which mode incomign REFERs will be processed. They are either rejected, forwarded or handled locally.
    • Parameters: REFER-processing mode