Skip to content

Cloud Native

API Exposure Functions

SIP

built by slicce

Develop 4G Intelligent Network Services using SIP protocol

ISC (IMS Service Control Interface) AEF exposes SIP APIs and allows the implementation of intelligent services for IMS and VoLTE networks. Exposes 2 different sets of APIs, IMS Service Control Function API and IMS Media Resource Function Control API.

  • Rapid development of IN services
  • Use REST APIs in any coding language
  • Comes with our without data store
  • Multi-Function AS, B2BUA, MRFC, PROXY, REDIRECT

ISC API Exposure Function makes advanced call control, voice & video service logic simple and accessible.

The ISC interface connects the CSCF and the IMS core network components, allowing the Call Session Control Function (CSCF) to interact with other IMS core network entities (like the P-CSCF (Proxy-CSCF), I-CSCF (Interrogating-CSCF), S-CSCF (Serving-CSCF)) to facilitate VoLTE calls.

Multimedia services, such as video calling, messaging, and data sharing, rely on the IMS architecture to function properly. The ISC interface ensures that various multimedia components in the IMS network work together to provide end-to-end services.

The ISC AEF microservice helps developers build and deploy VoLTE and multimedia services by providing a flexible, cloud-native platform. It enables easy integration with IMS core components like CSCFs, facilitating seamless voice, video calls, and messaging over LTE networks.

Key Benefits for Developers:

  • Microservices architecture: Modular, scalable services for quicker development and deployment.
  • IMS integration: Easy access to IMS functions (call control, media management, session management).
  • APIs: Simple API exposure for developers to interact with network functions like VoLTE call setup and QoS.
  • Real-time control: Allows real-time session and media management for dynamic service adjustments.
  • Cross-network support: Develop services that work across LTE, Wi-Fi, and other networks.
  • Control media resources: Seamless management of network Media Resource Functions.
  • Cloud-native: Scalability and flexibility using cloud technologies.
  • Personalization: Tailored services based on user profiles.
  • 5G Ready: Supports future migration to 5G networks.

In summary, ISC AEF simplifies the development of advanced, scalable, and customizable VoLTE and multimedia applications over LTE, with real-time control, cloud capabilities, and ready integration with emerging 5G services.

Cloud Native api exposure functions CAMEL gateway DIAMETER gateway SIP gateway MAP gateway USSD gateway SMS gateway SMS and Charging Interworking functions cloud native SS7 load balancers cloud native diameter load balancer cloud native sip load balancer cloud native GTP load balancer

Implements a multi-volte services based on IFC (Initial Filter Criterias) triggers

Initial Filter Criteria (IFC) are used in the IMS (IP Multimedia Subsystem) architecture, specifically within the CSCF (Call Session Control Function), to route incoming sessions (like voice or video calls) and trigger services in external Application Servers (AS) based on predefined conditions. The SIP AEF also called ISC AEF is a tool to rapidly depoy tne external AS in the IMS network.

Here’s a high-level overview of how IFCs are used in the process:

  • Session initiation: When an IMS-based session is initiated (such as a voice or video call), the CSCF intercepts the signaling (typically SIP messages) and looks for the Initial Filter Criteria (IFC). These criteria are defined by the HSS (Home Subscriber Server) or external entities to identify specific types of sessions (e.g., a VoLTE call or a video conference).
  • IFC matching: The CSCF checks the incoming session against the IFC rules, which are conditions like caller identity, called party identity, service type, or network conditions. These filters are part of the session’s setup information and are used to determine which external Application Server (AS) should be involved in the session.
  • Triggering services: If a session matches an IFC rule, the CSCF triggers a service or application in an external Application Server (AS). This could involve various services such as: Call forwarding, Video conferencing, RCS (Rich Communication Services) features
    VoLTE-specific features like supplementary services. The CSCF communicates with the AS using SIP protocol to trigger the service, passing along the necessary information to the AS to process the request.
  • Execution of services: The Application Server processes the request and applies the required logic. For instance, it might decide to route a call differently, initiate a video session, or invoke a feature like call recording or voicemail. The AS then communicates back to the CSCF with instructions on how to proceed, such as modifying the session, allowing the service to proceed, or applying specific user preferences.
  • Session continuation or termination: After the service has been applied (or if no service is needed), the CSCF continues processing the session, either continuing the call or terminating it, based on the service logic from the AS.
ISC-AEF Standalone mode, SIP API with multiple multimedia services ISC-AEF Standalone mode, SIP API with multiple multimedia services

Expose SIP API to 3rd pary domain with the CAPIF Core Function

MNO (Mobile Network Operator) would most typically expose APIs to MVNOs (Mobile Virtual Network Operator) to enable better integration and interoperability between their services. By exposing APIs, MNO can allow MVNO to access its network resources, such as billing, authentication, provisioning, and customer care. This can benefit both parties by reducing operational costs, improving customer satisfaction, and creating new revenue streams. For example, MVNO can offer customized plans and features to its subscribers using MNO’s network infrastructure, while MNO can leverage MVNO’s market reach and brand loyalty.

ISC-AEF CAPIF mode, SIP API with 3rd Party Exposure ISC-AEF CAPIF mode, SIP API with 3rd Party Exposure

functional specs

SIP stackRFC 3261 | SIP: session initiation protocol RFC 3262 | SIP reliability (PRACK) RFC 3263 | SIP: locating SIP servers RFC 3264 | SDP offer/answer RFC 3265 | SIP-Specific event notification RFC 1321 | MD5: message digest algorithm RFC 2617 | HTTP authentication RFC 2806 | URLs for telephone calls RFC 2833 | RTP payload for DTMF & tones RFC 2915 | NAPTR: naming authority pointer RFC 2976 | SIP INFO method RFC 3204 | MIME objects for ISUP and QSIG RFC 3310 | HTTP digest authentication – AKA RFC 3311 | SIP update method RFC 3329 | Security mechanism for SIP RFC 3428 | SIP extension for IM RFC 3489 | STUN: simple traversal UDP - NATs RFC 3515 | SIP refer method RFC 3581 | Symmetric response routing ext’n RFC 3665 | SIP basic call flow examples RFC 3711 | SRTP secure RTP RFC 3891 | SIP replaces header RFC 3903 | SIMPLE SIP for IM and presence RFC 4028 | Session timers in SIP RFC 4346 | TLS transport layer security RFC 4566 | SDP session descrip’n protocol/IPv6 RFC 4568 | SDP security for media streams
API interfaceHTTP/1.1, HTTPS, HTTP/2.0
MRF controlRFC 5707 - Media server markup language
Software packagingSoftware packaging

Let'sconnect

Telecom is our expertise