Manual Chapter : SIP Overview
Applies To:Show Versions
- 17.1.0, 17.0.0, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0
This section provides a concise summary of the BIG-IP® MRF SIP solution.
- Route SIP control messages, without modifying SIP headers.
- The following headers can be configured to be automatically modified.
- VIA Header inserted
- Record Router Header inserted
- Decrementing max forwards
- Any header attribute can be modified via iRule.
- Natively route messages based on:
- From URI
- To URI
- Request URI
- Originating Virtual Server
- Route messages via iRule on any attribute of the message.
- Response routing natively using data added to the inserted VIA Header.
- Response routing available via iRule:
- Add private header to request
- Insertion of VIA Header to request via iRule
- Route to upstream device using received VIA Header
- Remember data from request processing
- Bi-directional persistence support.
- Persistence key selection via configuration or custom key via iRule
- Connection Re-Use Support
- High Availability (HA)
- Connection mirroring
- Persistence table replication
ALG without SNAT (No Address
- Snoop control messages flowing through to manage media flows.
- iRule can be used to rewrite headers.
- Create media records in session db.
- Create deny listeners to drop media packets received before the callee responds with its media details.
- Create media flows to forward packets between caller and callee.
- High Availability (HA)
- Call table replication (supports failback)
- Control connection mirroring (can be recreated on failback by endpoint)
- Media flow mirroring
SRTP Compliance (RFC 3711)
We do not support SRTP in ALG without SNAT mode.
When operating in ALG mode, the system does not have access to any verifiably authoritative source of information about which endpoints or users should be allowed access to media connections, and does not actively control or restrict the messaging in media channels. It is therefore possible for an attacker with access to a device inside a BIG-IP® system and a related SIP-proxy outside the BIG-IP system (e.g. on the Internet) to use the SIP-ALG feature to create arbitrary communications channels between those two devices via carefully crafted SIP messages, or to route non-call data via SIP-negotiated media channels.
Customers are expected to provide external control of SIP messaging that would make use of the SIP ALG feature, mitigating this concern by transferring the risk to their SIP controller.