5.9. Media Handling

5.9.1. Introduction

In SIP networks, the signalling and media packets may traverse different paths and may be handled by different servers in the path. The ABC SBC can be on both the signalling path and the media path, or only on the signalling path of a call.

In the SIP signalling, the IP addresses between which the actual media is exchanged is negotiated using Session Description Protocol (SDP). The default signaling mode establishes a direct media path between the two call parties as shown in Chart I of Figure RTP Anchoring with and without Symmetric Mode. If the ABC SBC is configured to intervene and insert itself in the media path, it replaces IP addresses in SDP signaling with its own, attracts RTP packets to itself and forwards them to the other call party, as shown in Chart I and II.

_images/natflow.png

Figure 1: RTP Anchoring with and without Symmetric Mode

Generally it is desirable to have RTP processed and relayed at as few network elements as possible, in order to maintain lowest possible total latency and delay variations (jitter). Performance impact of media relay is discussed in more detail in Section SBC Dimensioning and Performance Tuning. However, the ABC SBC must be inserted in the media path in the following quite common situations:

  • NAT handling - User Agents that are behind a NAT are not able to send RTP directly to other User Agents behind NAT
  • Connecting unroutable networks – when the ABC SBC connects networks that cannot directly send packets between themselves, media anchoring must be enabled.
  • Topology hiding - to improve end point and network security, the ABC SBC prevents entities from learning the addresses of other entities in the network
  • Bandwidth limitations - the ABC SBC can limit the bandwidth used by one call to the amount that is necessary in order to prevent denial of service attacks, see Sec. Traffic Limiting and Shaping for more details.
  • Traffic monitoring - the ABC SBC can be used to monitor the amount of media traffic used
  • RTP filtering - the ABC SBC can filter unknown or not negotiated RTP packets
  • Logging and tracing - for troubleshooting call audio quality issues, the ABC SBC can be used to get a trace of the traffic including RTP packets
  • Recording for sake of monitoring, archival or lawful interception - in any of these case the operator must relay RTP packets in order to record the audio.
  • Quality assurance - especially when protecting a hosted PBX service it is often needed to record incoming calls. In order for the the ABC SBC can support this feature, RTP anchoring is needed.
  • WebRTC gateway - in this mode the ABC SBC must receive the media flows to be able to convert them between plain RTP and secured DTLS-SRTP.

5.9.2. Media Anchoring (RTP Relay)

Media anchoring is activated by applying the Enable RTP anchoring  action on a call in the A or C rules of either source or destination Call Agent or Realm. This action may be activated several times on a call, however, once activated it can not be deactivated for that call. Executing this action is a prerequisity for many other actions described in this section, they will otherwise not work properly.

_images/media_anchor_config.png

Figure 2: Media anchoring configuration

The following sub-sections described in more detail respective configuration options of media anchoring.

5.9.2.1. RTP, RTCP and FAX (T.38) Relay

If media anchoring is activated, both RTP and RTCP packets are relayed for a call. Also, Facsimile over RTP and over UDPTL (T.38) is relayed by the ABC SBC. No configuration step is required, the ABC SBC forwards Fax automatically.

5.9.2.2. Symmetric RTP Mode and NATs

For User Agents behind a NAT - especially if both user agent are behind NATs - relaying media through the ABC SBC may alone not be enough to accomplish NAT traversal. The problem is the ABC SBC cannot easily determine the public IP address to which to relay RTP media for a SIP phone. The IP address advertised by the User Agents in their SDP payload is unroutable.

In a solution here called “Symmetric RTP” [1] (also called Comedia-style [2] RTP handling) the ABC SBC ignores IP address advertised in SDP and learns the IP address and UDP port number of the UA by observing RTP packets coming from the UA. It then starts sending the reverse RTP stream to that address. Symmetric RTP is activated by either one of:

  • SIP device, by inserting an “a=direction: active” property in the SDP
  • ABC SBC, by enforcing it using the “Force symmetric RTP for UA” option in the “Enable RTP anchoring” action

We recommend to leave this option turned on for all Call Agents in their both inbound and outbound rules. That not only works safely in most cases, but is also more secure in that it prevents use of bogus IP addresses in SDP payloads. Only when a Call Agent is a) known not to be implemented symmetrically AND b) is directly reachable without NATs in between, it makes sense to turn this option for the Call Agent off.

The RTP flows are depicted in Figure RTP Anchoring with and without Symmetric Mode. The chart I. shows RTP flows when no media anchoring is engaged. The RTP packets take then the “shortest path” without any SIP intermediary. This flow fails in presence of NATs because telephone’s private IP address advertised in SDP is not reachable for the peer device. The chart II shows RTP flows when media anchoring is enabled. The RTP flows from and to a SIP phone are not symmetric, i.e., they are sent from and to different UDP ports as advertised in SDP payload. Like in the chart I, NAT traveral will fail. The chart III shows symmetric RTP that is the safest option for NAT traversal. IP addresses in SDP payload are ignored and the ABC SBC relays media to a telephone to address from which phone’s RTP packets come.

5.9.2.3. Intelligent Relay (Media Path Optimization)

If the ABC SBC handles a call which is originating from the same network that it terminates to, it may be useful to skip media anchoring for that call, in order to save bandwidth and to reduce the total latency introduced. The ABC SBC detects that the caller and the callee are behind the same NAT and is so, bypasses media relay. The test is done by comparing source IP address of incoming INVITE to the intended destination of the request. This algorithm works only if both User Agents are behind the same NAT and there are no intermediary elements between the NAT and the ABC SBC. If this condition doesn’t hold, the optimization will fail. That may for example happen if two user agents from behind different NATs speak to the ABC SBC through an intermediary proxy server and appear to the ABC SBC as if they were behind the same IP address. Further, this algorithm does not detect UAs behind a NAT which controls multiple public IPs. Also, the signalling IP address of the callee used for the comparison is projected and does not support domain names.

_images/1000020100000485000002C4B5D98D3Eb.png

Figure 3: Intelligent relay

A separate header field, the “Source-IP header field”, is used to transport the information about the caller’s network through additional proxies in the signalling path. The header name may be configured as a property of the “Enable RTP anchoring” action, so that it can be customised and subsequently filtered out if necessary. This way, the ABC SBC can perform the “same-NAT” test even in scenario shown in Figure Intelligent relay and which a call passes the ABC SBC twice. Once on the way in, when source IP address is known but not the final destination , and then on the way out where the destination is already known but the source IP address would be uknown without the additional header-field.

5.9.2.4. Advanced Anchoring Options

Further media-anchoring options are useful for interaction with advanced clients that use newer protocols: ICE and STUN for NAT traversal, and also additional RTCP feedback for measuring QoS. Such clients are yet rare, however a new interoperability profile for WebRTC clients does actually include all of these. See also Section SIP-WebRTC Gateway. Other group of options are those related to keeping calls alive: they make sure that the ABC SBC and its communication peers will properly detect active calls as such, and timely detect calls that ended abruptly.

The following advances options are available:

  • Offer ICE-Lite – adds ICE-lite (server-side ICE) capability to SDP. This is a must for web-rtc clients that expect their peers to communicate using ICE. WebRTC Call Agents must thus have this option enabled in both A and C rules. It can be also useful for SIP-based User Agents if they support ICE – however generic ABC SBC NAT techniques do not require use of ICE for facilitating NAT traversal.
  • Offer RTCP Feedback – adds additional RTCP capabilities for sake of finer QoS monitoring than available in traditional RTP implementations. This is mostly useful for WebRTC implementions which include this extension in their interoperability profile.
  • Keepalives – allows to send keep-alive RTP traffic. This is useful if one side of a call detects and discontinues inactive calls whereas the other side supresses RTP due to Voice Inactivity Detection or On Hold scenarios. With this option turned on, the calls will not be discontinued.
  • Timeout – allows call termination when no RTP traffic appears. Useful to eliminate “hanging calls” due to abruptly disconnected SIP devices.

5.9.3. RTP and SRTP Interworking

The ABC SBC can also transform media between “plain-text” RTP and encrypted SRTP. This is particularly useful in SIP/WebRTC interworking scenarios detailed in Section SIP-WebRTC Gateway.

The action Force RTP/SRTP performs protocol admission in A-rules and protocol conversion in C-rules. When placed in A-rules, it only permits calls corresponding to the requested protocol, the calls will be rejected otherwise. When the action i placed in C-rules, it converts media to the chosen protocol. If the chosen protocol is SRTP, the keying protocol must be also chosen: DTLS or SDES. When the destination is an RTC client, the keying protocol must be DTLS since spring 2014.

_images/force_srtp.png

Figure 4: Enforce SRTP

5.9.4. SRTP End to End encryption

The action End to End encryption provides the capabilities to stay in the media path while not interfering in the SRTP negotiation. The SRTP key is negotiated by both peers without any intervention of the SBC, which is not able to encrypt/decrypt the media if this action is enabled.

5.9.5. Transcoding

To enable broader interoperability, the ABC SBC can transcode between different codecs, that is it will decode incoming RTP packets and encode RTP packets into a different codec. The ABC SBC currently supports transcoding for audio only, there is currently no support for transcoding video streams.

For transcoding to be available in the ABC SBC, the operator needs to get and install the proper license for the media processing package, see Sec. Installation Procedure for details. Also, for some codecs, patent licenses need to be acquired separately. For some codecs, special software packages need to be installed, please contact FRAFOS support if in doubt.

The FRAFOS ABC SBC supports software based transcoding. Transcoding adds non-negligible processing power requirements to the SBC hardware, see Sec. SBC Dimensioning and Performance Tuning for details.

Depending on the codecs used, transcoding also reduces voice fidelity, especially if transcoding is applied a multiple times on the path of the call.

The action Activate transcoding takes as parameter a comma-separated list of codecs which are added to the SDP offer, if not present in the original offer. The codecs listed here must be supported by the ABC SBC . If the other party accepts one of these, the media stream is transcoded. Both (or, all) codecs which the ABC SBC should transcode between need to be added to the list of transcoding codecs.

_images/10000000000003C20000002F5C8BCDE0.png

Figure 5: Activate transcoding

For example, if “pcmu,pcma” is configured as transcoding codecs, and the caller offers only PCMU and the called party PCMA, the ABC SBC transcodes from PCMU at one side to PCMA at the other side and the other way around. If both sides happen to support the same set of codecs then transcoding will not be needed and will not be used.

5.9.6. Audio Recording

Recording may be useful for a variety of purposes: most often for archival, monitoring and legal interception. If a call is selected for recording, the ABC SBC collects audio and stores it in a WAV file. Each direction is stored in one channel, the file is stored with sampling rate 8kHz, two bytes per sample (PCM), two channels. To allow recording, media anchoring must be turned on. Recording works only if supported codecs are used.

Recording is activated by the action Activate audio recording that takes a comma-separated destinations as parameter.

The destination may be a filename, a HTTP server to which the WAV file is uploaded using the PUT method or a SIP URI if the call recording is to be outsourced to a SIPREC call recording server. If a SIP URI is used, only one is supported and should not be entered as a list.

The call recording action supports two more parameters allowing for start and stop announcements. These annoucements are played when the recording starts or stops. Please note that the stop announcements can only be played if SIPREC is used, and the call recording server (SRS) does stop the recording before the call has been ended.

Replacement expressions can be used to provide easier identification of the system. USE CAUTION when devising the filename: filename conflicts will result in differnt sessions overwriting each other’s WAV file. If no filename is included, the ABC SBC uses its own ephemeral filename. Filenames are made relative to the directory /data/recordings to make sure that the recording doesn’t interfere with the filesystem.

_images/recording.png

Figure 6: Activate Audio Recording

When recording and generating the WAV files completes, an event is produced.

Note that to avoid premature deletion of important archival data, the system does not delete any audio files and keeps them stored. This may potentially exhaust the disk space. Consult professional services if you need help on managing audio archives.

5.9.7. Playing Audio Announcements

Often it is practical to inform caller about an error by an audio announcement rather than a numerical SIP code. The ABC SBC can play audio files on several different occasions for each of which there is an appropriate action:

  • “Refuse call with audio prompt” plays an audio file immediatelly on receipt of an INVITE
  • “Play Prompt on Final Response” plays an audio file on an unsuccessful call attempts
  • “Generate Ring-Back Tone” plays an audio file instead of the default ringing tone
  • “Activate Music On Hold” plays an audio file when a party chooses to put a call on hold

The action “Refuse call with audio prompt” plays a prerecorded audio WAV file immediatelly on receipt of a SIP INVITE. It is typically used to decline a call using a pre-recorded message. This action plays a prerecorded WAV audio file and terminates the call. It takes the following parameters:

  • filename of the announcement relative to the global configuration option “Prompts/Base Directory”. The filename must refer to an existing file which has been uploaded to the prompts directory by administrator.
  • a checkbox specifying whether the announcement shall be played as early media or etablish a regular call
  • a checkbox specifying whether the announcement shall be played once or in a loop
  • SIP response code, phrase and header-fields to be used for terminating early media announcement (unused if a regular call is established)
  • also instead of playing a pre-recorded WAV file, a beep tone can be generated. To turn it on, activate the “generate ringtone” checkbox and describe the tone length, on-off periods and frequencies.
_images/refuse_call.png

Figure 7: Example Action for Playing an Announcement

The same effect can be achieved for SIP calls that failed downstream. The action Play Prompt on Final Response plays an announcement for call attempts that failed downstream due to one of the listed failure codes. The announcement can be played as a regular call or as early media, in which case a specified SIP response code will conclude the announcement.

_images/play_prompt_on_fr.png

Figure 8: Example Action for Playing an Announcement on Receipt of a 404 Response

Also it may be useful to play specific tones or audio when called party’s telephone is ringing. To enable this functionality, use the action “Generate Ring-Back Tone” and either define a tone or reference to an audio file to be played instead of the default ringing tone. The screenshot in Figure Example Action for Playing an Audio File during Ringing is showing such a configuration that plays a predefined audio file during the ringing phase after the receipt of the UAS’s 180 response. Alternatively one could have played a predefined dual-frequency tone.

_images/ringback_rule.png

Figure 9: Example Action for Playing an Audio File during Ringing

Similarly it is possible to play an audio file whenever a party chooses to put a call on hold. The action takes several paramters that allow it to define how the on-hold status is signaled to the other call party and if the audio file is played once or in a loop.

_images/rule-onhold.png

Figure 10: Example Action to Activate an Audio File when a Call is Put on Hold

5.9.8. Onboard Conferencing

To accomodate smaller-scale dial-in conferences without need for an external conference bridge, the ABC SBC can mix audio calls. To enable a conference, place a “join meet-me conference” action in A rules. The action’s parameters allow to specify which conference an incoming call shall join: either by two-stage DTMF dialing, or by a “hard-wired” conference ID, or by conference ID determined using a replacement expression.

The following example configuration shows a conference bridge configured to serve calls from native SIP devices, SIP-based PSTN gateways and WebRTC browsers. SIP devices and WebRTC browsers are handled the same way: userpart of request URI ($rU) identifies the conference a caller is joining. Calls from the PSTN call-agents however are prompted to type in the conference id when dialing in.

_images/conference.png

Figure 11: Example Screenshot: Conference Bridge configuration

Note that the default WAV announcement files (like conference ID prompt, or “you’re welcome” message) are stored on the system in the directory /usr/lib/sems/audio/ and can only be changed through Command Line Interface. Also note that locally processed onboard conferencing calls do not appear in the list of live calls (see Section Live Calls) in which only relayed calls are represented.

The status of the conference bridge can be inspected using CLI as shown in the following example

[root@ec2-54-154-137-127 ~]# sems-stats -c "DI webconference listRooms verysecret"
sending 'DI webconference listRooms verysecret\n' to 127.0.0.1:5040
received:
[200, ['1234'], 'Server: Sip Express Media Server (3.1.1-79-c86706a-417e607-87219e5 (x86_64/linux)) calls: 1 active/0 total/0 connect/0 min']
[root@ec2-54-154-137-127 ~]# sems-stats -c "DI webconference roomInfo 1234 4447"
sending 'DI webconference roomInfo 1234 4447\n' to 127.0.0.1:5040
received:
[0, 'OK', [['020D64C4-54E33359000B632C-E54DD700', '"homer" <sip:homer@simpson.org>', 3, 'direct access: entered', 0, '']], 'Server: Sip Express Media Server (3.1.1-79-c86706a-417e607-87219e5 (x86_64/linux)) calls: 1 active/0 total/0 connect/0 min']
[root@ec2-54-154-137-127 ~]#

Footnotes

[1]The name “Symmetric RTP” is derived from the property of a UA that it sends RTP from the address/port combination where it expects to receive RTP at.
[2]The name “Comedia” came from an Internet Draft proposing use of “Connection Oriented Media”. The Internet draft draft-ietf-mmusic-sdp-comedia became eventually RFC 4145.