Whenever a SBC Edge (SBC) receives an ISDN Progress/Alert/Connect or a SIP 183/180/200 message, it is translated to the outgoing leg of the call. Although it may appear that incoming messages are simply copied from incomging to outgoing leg, in fact, they are run through an internal translation table to determine precisely what to send (on the outgoing leg).
The internal translation table is designed to work in the vast majority of circumstances; however, circumstance may dictate the need for a translation that differs from the pre-programmed translations. The Message Translation table provides the ability for the user to override the internal translations on a per Call Route basis.
This article outlines the various configuration parameters of the Message Translation functionality, how the parameters are used, and how to configure them to override the pre-programmed translations.
On this page:
Looking at the diagram below:
Whether it sends the 183 with or without SDP, or whether it even sends a 183, is controlled by the SBC's internal, pre-programmed translation table. The internal translation table controls the translation for ISDN Progress/Alert/Connect messages, as well as SIP 18x/200 messages for calls ISDN to SIP, SIP to ISDN, and SIP to SIP.
Although the internal translation table works for the majority of installations, it may be necessary to customize a translation. This is accomplished by creating an entry in the Message Translation table that
The first phase of the the Message Translation table works on the incoming message. When a message arrives, it is checked against all of the translations entries in the table, specifically the Incoming Message configuration.
Below a Progress with no Progress Indicator (PI=0) is shown with it's matching Incoming Message configuration. Similarly, a Progress with PI=1 (Not end to end ISDN) is shown with it's matching Incoming Message configuration.
SIP uses SDP to negotiate media connections. To establish a common media framework (codec, endpoint addresses, etc), an endpoint will send an SDP Offer - a list of the media that the endpoint can support. The recipient will Answer the SDP Offer with a list of media attributes that it endpoint will support for this particular session.
In the diagram below, an INVITE with SDP is sent to the SBC. This SDP is an Offer - a list of the media that the endpoint is offering to support. Later, the SBC replies with a 183 with SDP, essentially Answering the Offer with a media list that is acceptable for communication.
Once an SDP Offer has been Answered, the media is said to be Negotiated. Both sides are now able to send media based upon the negotiated SDP parameters.
Some applications cannot accept additional SDPs once the media has been negotiated, so the SBC includes an additional Incoming Message criteria that permits a translation to be matched based on whether media negotiation has been completed.
In the example below, the Early Media Status is set to Not Negotiated. As the SIP SDP Offer has not yet been answered, the media is indeed not yet negotiated and, therefore, the match passes. If the remaining Incoming Message matches as well, the translation entry will be used to translate the message to the SIP side.
In the example below, the Early Media Status is set to Negotiated. Since the media has yet to be negotiated (no SDP Answer has been sent), the match fails. That particular translation entry fails. The next translation entry, if there is one, will be checked.
In the example below, the media has been negotiated therefore Early Media Status will be matched. If the rest of the Incoming Message translation is matched, that translation will be used.
Setting the Early Media Status to ANY causes the translation to ignore the media state.
Because ISDN does not have a concept of negotiated media, set the Early Media Status to ANY for a translation that will be used by a call that originates from ISDN.
When a incoming message matches in the Incoming Message configuration, the second phase of the process is to send an outgoing message that conforms to the corresponding Outgoing configuration.
In the call setup below:
The translation table above contains just two entries. Each time a packet arrives, each entry is tried sequentially in top-to-bottom order.
You might notice that the Incoming Message format remains the same, even when the incoming message is SIP. The Message and IE Types do not change to SIP references because any given translation maybe used for either SIP or ISDN. A ISDN to SIP conversion table (below) will assist in selecting the appropriate desired parameters.
183 Session Progress
Most ISDN endpoints do not tolerate receiving more than one Progress or Alert, so the Outgoing translation configuration includes No on Subsquent and No on Cut Through to ensure that only one Progress or Alert is sent regardless of the number of incoming SIP 18X messages. These configuration settings are generally only used for ISDN to SIP calls.
The Media Cut Through parameter controls how the SBC handles early media for calls that have:
Because the Media Cut Through is part of Message Translation (which is applied at the call route), it is possible to override the Signal Group-level Play Ringback setting. In the table below, note how the Media Cut Through configuration interacts with SBC's Ringback setting.
Ringback Configuration/ Media Cut Through
Yes on Early Media
Local Ringback until 1st Inband Media
For SIP-originated calls, Media Cut Through should always be configured to Yes so that network signals like Busy can always be heard by the caller.
For ISDN-originated calls, configure the Media Cut Through to Yes on Early Media if you want the caller to hear inband ringing associated with 183w/SDP.
Below are some additional examples of ISDN messages and which Incoming Message configurations are matched and not matched.
If no match is found, or no table is assigned to the call route, the message is translated using the internal translation table.
The above translation is a commonly used to generate ringback when the inbound leg does not provide ALERT or 180.
Translation Tables are invoked at the Call Route level. The call route (below) is configured to use the Message Translation Table called msg xlation.
The msg xlation table contains two translation entries (detail for the second entry is displayed).
When a route containing a message translation table is used to route a call, each reply message is checked again the entries in the selected table.
For a listing of the pre-programmed Message Translations on the SBC, see Message Translation Reference.