SIP support with Message Routing Framework (MRF)

F5 BIG-IP LTM on Cloud-Native Network Functions (CNF) supports Session Initiation Protocol (SIP) traffic management using the Message Routing Framework (MRF). MRF provides a flexible way to route SIP messages to backend servers based on message content, URI patterns, and routing policies.

You configure SIP settings in an F5SipSetting custom resource (CR). The CR combines session profile, router profile, routing rules, and peer configuration into a single resource. You then attach the SIP settings to a virtual server by name.

Architecture

The SIP configuration in the F5SipSetting CR maps to several underlying components:

CRD section TMOS equivalent Purpose
session SIP session profile Controls session behavior, persistence, Via headers, loop detection, message size limits, and SIP firewall settings.
router SIP router profile Defines the routing operation mode (load balancing or Application-Level Gateway), pending message limits, retry behavior, and per-peer statistics.
persistence SIP persistence config Configures persistence matching across pools, services, and virtual servers.
routes SIP routes and peers Defines static SIP routes with URI-based matching patterns and associated peer configurations.
routes[].peers[].transport SIP transport config Specifies transport settings for peer connections, including profiles, iRules, SNAT, and source port behavior.

Operation modes

The router.operationMode field supports one mode:

  • LoadBalancing — Routes SIP messages to pools based on routing rules and peer configurations. This is the default and only supported mode.

Session configuration highlights

  • Persistence — Choose from Session or None persistence types, with keys based on Call-ID, Custom, or Src-Addr.

  • Via header handling — Insert and honor Via headers for response routing. Required when loop detection is enabled.

  • Loop detection — Available in Loose or Strict mode. Requires insertViaHeader to be true. Loose mode skips the To attribute in the hash calculation.

  • Message limits — Control maximum message size, header count, and header size.

  • SIP firewall — Enable SIP-specific firewall inspection with the enableSipFirewall field.

  • Routing headers — Insert Record-Route headers using Single (RFC 3261) or Double (RFC 5658) mode. Honor Route headers using Loose (RFC 3261) or Strict (RFC 2543) mode.

Route and peer configuration

Routes match SIP messages using three URI patterns:

  • requestUri — Matches the Request-URI of the SIP message.

  • fromUri — Matches the From header URI.

  • toUri — Matches the To header URI.

Each route contains one or more peers. Peers are selected using either Sequential or Ratio mode. Each peer defines:

  • A connection mode (PerPeer or PerClient)

  • A target pool

  • A transport configuration with a required protocol profile

  • Optional SNAT, source port, and iRules settings

  • Optional auto-initialization for pre-established connections

Virtual server attachment

You attach SIP settings to a virtual server using the sip field in the F5VirtualServer CR. This field accepts the name of an F5SipSetting CR in the same namespace.

SIP pool monitor

You can monitor SIP pool members using a SIP-specific health monitor configured in the F5BigCnePool CR. The monitor supports five transport modes: udp (default), tcp, tls, sips, and sctp. All modes use the Message Routing Framework. A maximum of one SIP monitor is allowed per pool.

Configure SIP load balancing with MRF

Use this guide to configure SIP traffic management using the MRF on F5 BIG-IP LTM on CNF. You’ll create a SIP settings resource, define routes and peers, and attach the SIP profile to a virtual server.

Before you begin

  • You have a working F5 BIG-IP LTM on CNF deployment.

  • You have kubectl access to the cluster namespace.

  • You have pools configured for your SIP backend servers.

  • You have protocol profiles (TCP or UDP) created for your SIP transport configuration.

Create the SIP settings resource

  1. Create an F5SipSetting CR manifest. This example configures load balancing mode with two routes, each pointing to different pools:

apiVersion: k8s.f5net.com/v1
kind: F5SipSetting
metadata:
  name: sip-multi-route
  namespace: default
spec:
  session:
    persistType: Session
    persistKey: Call-ID
    persistTimeout: 3600
    honorVia: true
    insertViaHeader: true
    allowUnknownMethods: false
    maxMsgSize: 32768
    servicePort: 5060
    enableSipFirewall: true
    loopDetection:
      enabled: true
      mode: Strict
    routingHeaders:
      insertRecordRouteHeaders: true
      recordRouteMode: Double
      honorRouteHeaders: true
      honorRouteMode: Strict
  router:
    operationMode: LoadBalancing
    maxPendingMessages: 4096
    maxPendingBytes: 32768
    maxRetries: 1
    perPeerStats: true
    useLocalConnection: true
  routes:
    - requestUri: "sip:.*@us-east.example.com"
      fromUri: ""
      toUri: ""
      virtualServer: "vs-sip-us-east"
      peerSelectionMode: Ratio
      peers:
        - connectionMode: PerPeer
          pool: pool-us-east-primary
          ratio: 7
          numberConnections: 1000
          autoInitialization: true
          autoInitializationIntervalMs: 5000
          transportConfig:
            protocol: udp
            protocolProfile: sip-udp-profile
            snat:
              type: automap
            sourcePortMode: preserve
        - connectionMode: PerPeer
          pool: pool-us-east-secondary
          ratio: 3
          numberConnections: 500
          autoInitialization: true
          transportConfig:
            protocol: udp
            protocolProfile: sip-udp-profile
            snat:
              type: automap
    - requestUri: "sip:.*@eu-west.example.com"
      fromUri: ""
      toUri: ""
      virtualServer: "vs-sip-eu-west"
      peerSelectionMode: Sequential
      peers:
        - connectionMode: PerClient
          pool: pool-eu-west-primary
          ratio: 1
          numberConnections: 2000
          autoInitialization: true
          transportConfig:
            protocol: tcp
            protocolProfile: sip-tcp-profile
            snat:
              type: snat
              pool: my-snat-pool
            sourcePort: 5061
            sourcePortMode: change

  1. Apply the manifest.

kubectl apply -f sip-settings.yaml

Attach SIP settings to a virtual server

  1. Reference the SIP settings by name in the sip field of your F5VirtualServer CR:

apiVersion: k8s.f5net.com/v1
kind: F5VirtualServer
metadata:
  name: sip-vs
  namespace: default
spec:
  destinationAddress: 10.10.10.100
  destinationPort: 5060
  protocol: udp
  sip: sip-multi-route
  pool: sip-pool
  snat:
    type: automap

  1. Apply the manifest.

kubectl apply -f sip-virtual-server.yaml

The sip field is a string that references the name of an F5SipSetting CR in the same namespace. The maximum length is 255 characters.

Verify the configuration

  • Check the SIP settings resource:

    kubectl get f5sipsetting sip-multi-route -n default -o yaml

    Confirm that all sections (session, router, routes) are present and correct.

  • Check the virtual server.

    kubectl get f5virtualserver sip-vs -n default -o yaml

    Confirm that the sip field shows your SIP settings resource name.

Configure a SIP pool monitor

Use this section to set up a SIP-specific health monitor for a pool on F5 BIG-IP LTM on CNF. A SIP monitor sends SIP requests (such as OPTIONS) to pool members and checks their responses to determine health.

Before you begin

  • You have a working F5 BIG-IP LTM on CNF deployment.

  • You have kubectl access to the cluster namespace.

  • You have pool members that accept SIP traffic.

Supported transport modes

The SIP monitor uses the Message Routing Framework (MRF) for all transport modes. Choose the mode that matches your SIP infrastructure:

Mode Description
udp SIP over UDP. This is the default.
tcp SIP over TCP.
tls SIP over TLS.
sips SIP over secure transport (SIPS URI scheme).
sctp SIP over Stream Control Transmission Protocol (SCTP).

Create a pool with a SIP monitor

  1. Create an F5BigCnePool CR with a SIP monitor configuration. This example uses UDP transport and sends a SIP OPTIONS request:

apiVersion: k8s.f5net.com/v1
kind: F5BigCnePool
metadata:
  name: sip-pool-monitor
  namespace: default
spec:
  minActiveMembers: 1
  members:
    - address: 22.22.22.100
      port: 5060
      priorityGroup: 0
  monitors:
    sip:
      - mode: udp
        interval: 5
        timeout: 16
        upInterval: 10
        timeUntilUp: 0
        downCount: 3
        upCount: 1
        request: "OPTIONS sip:healthcheck@example.com SIP/2.0"
        headers: |
          Via: SIP/2.0/UDP 10.10.10.55:5060
          From: <sip:monitor@example.com>
          To: <sip:healthcheck@example.com>
          Call-ID: health-check-call-id
          CSeq: 1 OPTIONS
        filter: ""
        filterNeg: ""

Note

Only one SIP monitor is allowed per pool.

  1. Apply the manifest.

kubectl apply -f sip-pool.yaml

  1. Verify monitor health and check the pool resource to confirm the SIP monitor is active.

kubectl get f5bigcnepool sip-pool-monitor -n default -o yaml

Confirm that the monitors.sip section appears in the output with your configured values.