Media Resource Function
Core Function
MRF-CF is a purpose-built media server that plays announcements, collects DTMF digits and bridges basic conferencing on command from an external call-control application. It terminates the SIP dialog and executes the media instructions it's given; it doesn't decide on its own when an announcement plays or a call gets screened — that decision belongs to the application driving it.
Features & Benefits
Announcement and digit collection,
driven over standard SIP signalling
An external application sends an INVITE and then drives the call with SIP INFO messages carrying MSML instructions — play an announcement, collect a PIN, join a conference, end the dialog. No proprietary control channel: the media commands ride inside the SIP dialog itself.
Native AMR and AMR-WB playback,
transcoding only when it's actually needed
Stored AMR and AMR-WB prompts are re-framed directly into RTP without touching a codec, saving the CPU cost of transcoding — and MRF-CF checks the negotiated codec mode on each call and falls back to full transcoding automatically the moment a native match isn't possible.
Built for a real call-screening flow,
not generic conferencing
The shipped prompt set and end-to-end test implement a PIN-gated call-screening scenario: a prompt, a limited number of retries, a success announcement, hold music while the call bridges. Conferencing exists as a thin join/create primitive on top of it, not a full conference platform.
Per-country ring tones and hold music,
ready to use
Ringback tone and hold-music definitions are configured for use by any dialog that requests them, without additional setup per deployment.
Media on command from the call controller
ISC-AEF drives the dialog, MRF-CF executes the media instructions
MRF-CF doesn't originate or bridge calls on its own — an external B2BUA (ISC-AEF in the Slicce catalog) sends the initial INVITE, and MRF-CF answers as a single user agent, then executes whatever MSML instructions arrive over SIP INFO for the rest of that dialog: play a prompt, collect digits, join or leave a conference, end the dialog.
The call itself — the two legs, the bridging decision, the business logic — is the B2BUA's responsibility throughout.
The whole path sits inside the operator domain — MRF-CF has no CAPIF client, no REST API of its own and no northbound interface beyond the SIP dialog itself, so no 3rd party API exposure mode applies to MRF-CF directly; any third-party exposure happens one layer up, at the B2BUA (ISC-AEF) driving it.
Technical specifications
Northbound
SIP INVITE + SIP INFO carrying MSML instructions, from an external B2BUA — Slicce internal, MSML vocabulary per IETF RFC 5707
Southbound / Media
SIP — IETF RFC 3261
SDP offer/answer — IETF RFC 3264
AMR / AMR-WB storage and RTP payload — IETF RFC 4867
NETANN announcements — IETF RFC 4240
DTMF (telephone-event) — IETF RFC 4733
SIP preconditions (QoS gating, handled by the calling B2BUA, not MRF-CF) — IETF RFC 3312 / RFC 3311
Architecture
No 3GPP architecture document (TS 23.228 IMS/MRF, or an MSCML/Mr-Mp interface) is implemented or referenced — the "MRF" name reflects the role this product plays in the Slicce catalog, not a standards-conformance claim.
Ask us for the swagger file...
Contact us