Aller au contenu principal

SIP Trunking

This document covers SIP peer configuration, OPTIONS keepalive monitoring, SDP codec negotiation, in-dialog re-INVITE handling, session timers, DTMF relay, and SIP trunk call states in OmniMSC.

For SIP-related routing, see Routing Configuration. For SIP with encapsulated ISUP, see SIP-I Trunking. For SIP trunk troubleshooting, see Troubleshooting Guide. For call flow sequences showing SIP signaling in context, see Call Flow Diagrams. For media gateway codec negotiation, see Media Control. For SIP peer configuration parameters, see Configuration Reference.


SIP Peer Configuration

Each SIP peer represents a remote endpoint such as a VoIP gateway, SBC, IMS node, or SIP trunking provider. Peers are defined in the :sip configuration block and referenced by name in the route table.

ParameterTypeDefaultDescription
namestring-- (required)Logical peer name. Referenced in route table entries.
addressstring-- (required)Peer IP address or hostname.
portinteger5060Peer SIP port.
transportatom:udpTransport protocol: :udp, :tcp, or :tls.
codecslist(atom)[:pcmu, :pcma]Supported audio codecs for SDP negotiation.
max_channelsinteger100Maximum concurrent calls to this peer.
options_intervalinteger or nilnilInterval in seconds for SIP OPTIONS keepalive probes.

OmniMSC identifies itself with the User-Agent header OmniMSC/0.1 in all outgoing SIP requests and responses.


SIP OPTIONS Keepalive

When options_interval is configured for a peer, the SIP Peer Manager sends periodic SIP OPTIONS requests to monitor peer health. The peer status determines whether the peer is eligible for call routing.

Peer Health States

Each peer tracks a status of :up, :down, or :unknown. On startup, all peers begin in the :unknown state.

EventTransitionEffect
OPTIONS 200 OK receivedAny -> upPeer eligible for routing
Consecutive OPTIONS timeoutsup/unknown -> downPeer excluded from routing, alarm raised
OPTIONS 200 OK after downdown -> upPeer re-eligible, alarm cleared
max_channels reachedup -> up (soft limit)New calls rejected for this peer, existing calls unaffected

For SIP peer monitoring in the control panel, see Control Panel Guide.

Connections page showing SIP peer status (UP/DOWN/UNKNOWN) alongside STP link and known BSCs.


MO Call SIP Flow

When OmniMSC routes a mobile-originating call to a SIP peer, the following SIP signaling exchange takes place between OmniMSC and the remote peer.

The INVITE carries an SDP offer with codecs based on the peer configuration and BSC capabilities. The 200 OK contains the SDP answer with the selected codec and remote RTP address. After ACK, the RTP media path is established through the media gateway.


In-Dialog Re-INVITE Handling

A SIP peer may send a re-INVITE within an established dialog for several purposes: call hold, codec change, or session refresh. OmniMSC processes re-INVITEs and responds with 200 OK using the current session SDP.

Re-INVITE PurposeSDP IndicatorOmniMSC Behavior
Call holda=sendonlyAcknowledge hold, update MGW mode to recvonly
Call resumea=sendrecvResume media, update MGW mode to sendrecv
Codec changeModified m= lineRenegotiate codec if supported, reject with 488 if not
Session refreshNo SDP changeRespond with 200 OK, reset session timer

When OmniMSC receives a re-INVITE it cannot accept (unsupported codec, missing SDP), it responds with 488 Not Acceptable Here. The existing dialog and media session remain unaffected.


Session Timer (RFC 4028)

OmniMSC supports SIP session timers per RFC 4028 to detect and clean up orphaned SIP sessions. Session timers ensure that both endpoints periodically refresh the session, preventing stale call state after network failures.

ParameterValueDescription
Session-Expires1800s (default)Maximum time between session refreshes
Min-SE90sMinimum acceptable Session-Expires value
RefresherUAC or UASDetermined during negotiation

Session Timer Negotiation

OmniMSC includes the Session-Expires and Min-SE headers in outgoing INVITE requests and 200 OK responses. When a peer proposes a Session-Expires value below the configured Min-SE, OmniMSC responds with 422 Session Interval Too Small and includes the Min-SE header indicating the minimum acceptable value.

Session refresh is performed via re-INVITE. If no refresh arrives before the session expires, OmniMSC sends BYE to tear down the call and releases all associated resources.


DTMF Relay

OmniMSC relays DTMF tones using SIP INFO messages per the application/dtmf-relay content type. This method is used when the peer does not support RFC 2833 telephone-event RTP payload or when out-of-band DTMF is preferred.

FieldDescriptionExample
Content-TypeMIME type for DTMF relayapplication/dtmf-relay
SignalDTMF digit (0-9, *, #, A-D)Signal=5
DurationTone duration in millisecondsDuration=160

When DTMF events are detected from the radio side (via the media gateway), OmniMSC generates a SIP INFO message toward the SIP peer with the corresponding signal and duration. In the reverse direction, incoming SIP INFO DTMF events are forwarded to the media gateway for playout toward the mobile station.


SDP Codec Negotiation

OmniMSC generates SDP offers based on the intersection of the peer's configured codec list and the BSC-reported speech codec capabilities. Codecs are offered in preference order.

Supported Codecs

CodecRTP Payload TypeBandwidthfmtp Parameters
AMRdynamic (96)4.75-12.2 kbpsoctet-align=1
GSM-EFRdynamic (97)12.2 kbps--
GSM-FR313 kbps--

AMR is offered with octet-align=1 (RFC 4867) for interoperability with 3GPP access networks. GSM-EFR and GSM-FR are offered when the BSC indicates support for these codecs in the speech version list during assignment.

Codec Selection

The codec selection follows the SDP Offer/Answer model (RFC 3264):

  1. OmniMSC builds the SDP offer from the peer codec list, filtered by BSC speech capabilities.
  2. The remote peer responds with an SDP answer containing one or more accepted codecs.
  3. OmniMSC selects the first common codec from the original offer order.
  4. The media gateway is instructed (via MDCX) with the selected codec and RTP parameters.

If no common codec exists, OmniMSC responds with or receives 488 Not Acceptable Here.


SIP Trunk Call States

Outgoing Call States

Incoming Call States


References

ReferenceTitleRelevance
RFC 3261SIP: Session Initiation ProtocolCore SIP signaling
RFC 4028Session Timers in SIPSession-Expires, Min-SE, refresh mechanism
RFC 2833RTP Payload for DTMF DigitsTelephone-event RTP payload type
RFC 3264Offer/Answer Model with SDPSDP codec negotiation
RFC 4867RTP Payload Format for AMR and AMR-WBAMR octet-align parameter
RFC 3326Reason Header FieldCause code in BYE/CANCEL