Gateways

Gateway object defines SIP and RTP stacks behavior for interaction with remote systems. Gateway that defines LegA behavior called origination gateway. Gateway that defines LegB behavior called termination gateway.

For configure gateway it is necessary to configure Contractor. Also it is necessary to choose some Codec group

General attributes

Id

Unique gateway id.

UUID

Universally unique identifier of the gateway, auto-generated on creation. Unlike the numeric Id, the UUID is globally unique across distributed systems and database instances. It is used for identifying gateways in external integrations and API calls where numeric IDs may conflict.

Name

Friendly name of gateway.

External Id

Optional identifier used to reference this Gateway from an external system (e.g. billing platform, CRM). The value is exported in CDR records as orig_gw_external_id / term_gw_external_id.

Enabled

Disabled gateways will be ignored.

Contractor

Gateway's owner.

Is shared

Allows Gateway to be used as origination equipment for any customer or as termination equipment for any vendor.

Gateway group

Gateway Group gateway belongs to.

Priority

Gateway priority in the Gateway Group. In case of termination to the group, gateways will be arranged according to this priority. If few gateways have same priority, calls will be balanced between them.

Weight

Gateway weight in the Gateway Group.

Pop

Point of Presence of the gateway. Allows forcing gateway prioritization based on gateway location and call processing node. Read more in Gateway Group documentation

WARNING

Priority, Weight and Pop attributes only affects call processing when Gateway belongs to Gateway Group and calls routed to this Gateway Group. Read more about Priority, Weight and Pop processing at Gateway Group documentation

Scheduler

Optional Scheduler that automatically enables or disables this Gateway based on configured time ranges.

Allow origination

Specifies if gateway allowed to originate calls.

Allow termination

Specifies if Yeti-Switch allowed to send calls to this gateway.

Origination capacity

Concurrent calls limit for this gateway when it acts as origination gateway.

INFO

When Origination gateway capacity/CPS overloaded system will reject call. CDR will be saved.

Termination capacity

Concurrent calls limit for this gateway when it acts as termination gateway.

Termination subscriber capacity

How many concurrent calls allowed to single destination number via this gateway.

Termination CPS limit

How many new calls allowed within Termination CPS wsize interval via this gateway. Enforced cluster-wide across all nodes.

Termination CPS wsize

Window size for Termination CPS limit in seconds.

Termination subscriber CPS limit

How many new calls allowed within Termination subscriber CPS wsize time interval via this gateway to single destination number. Enforced cluster-wide across all nodes.

Termination subscriber CPS wsize

Window size for Termination subscriber CPS limit in seconds.

INFO

When termination gateway capacity/CPS overloaded system will try to reroute call to other routes if possible.

WARNING

Termination subscriber capacity, Termination CPS limit, Termination subscriber CPS limit are experimental features and not enabled by default.

Acd limit

ACD threshold. If ACD for gateway traffic is below the threshold, the Dialpeers that are used by this Gateway will be excluded from the routing in case of usage of routing plan with ACD&ASR control.

Asr limit

ASR threshold. If ASR for gateway traffic is below the threshold, the Dialpeers that are used by this Gateway will be excluded from the routing in case of usage of routing plan with ACD&ASR control.

Short Calls limit

Threshold percentage of Short Calls. If the current value is below the threshold, the Dialpeers that are used by this Gateway will be excluded from the routing in case of usage of routing plan with ACD&ASR control.

SST attributes

SST is SIP session timers

SST Enabled

Force to use SIP Session Timers, otherwise SST usage will be controlled by signaling of the remote gateway.

SST Session Expires

Default value (in seconds) of Expires header for SIP session timers mechanism.

SST Minimum timer

Minimum value (in seconds) of SIP Session Timer that will be accepted by Yeti.

SST Maximum timer

Maximum value (in seconds) of SIP Session Timer that will be accepted by Yeti.

Session refresh method

Mechanism of Session refresh. Possible values:

Invite

re-INVITE request will be used for a periodic refresh of SIP sessions.

Update Request

UPDATE request will be used for a periodic refresh of SIP sessions.

Update Request and Invite if unsupported:

UPDATE request will be used for a periodic refresh of SIP sessions only in case of supporting UPDATE by remote side (it is included into Allow header), otherwise re-INVITE request will be used.

SST Accept501

If it is enabled Yeti won't terminate a call in case of receiving "501 Not Implemented" on the answer on UPDATE request, otherwise call will be terminated in case of receiving "501 Not Implemented" from remote side.

Read more: RFC 4028 Session Timers in the Session Initiation Protocol (SIP)

Sensor attributes

Sensor level

Traffic mirroring mode. Possible values:

• Signaling
• RTP
• Signaling + RTP

Sensor

Sensor to mirror traffic. Mirroring is disabled if not set.

Signaling attributes

Relay options

Transparent relay of In-dialog OPTIONS between call legs.

Relay reinvite

Transparent relay of In-dialog re-INVITE between call legs.

Relay hold

Transparent relay of In-dialog re-INVITE with hold/unhold requests between call legs.

Relay PRACK

Transparent relay of In-dialog PRACK between call legs.

Rel100 mode

Reliability of Provisional Responses mechanism mode. Read more in RFC 3262. Possible values:

Disabled

• Reply with 420 Bad Extension if 100rel required and ignore it if supported in incoming INVITE.
• Ignore 100rel related headers.

Supported

• Add 100rel to Supported header for outgoing INVITE requests.
• Process extension related things according to RFC 3262.

Supported not announced

• Doesn't add 100rel to any header for outgoing INVITE requests, but enables 100rel processing if reply contains 100rel in Require header.
• Process extension related things according to RFC 3262.

Require

• Add 100rel to Require header for outgoing INVITE requests.
• Reply with 421 Extension Required if 100rel is not supported or required in incoming INVITE.
• Hangup session if no Rseq in incoming reply.
• Process extension related things according to RFC 3262.

Ignored

Completely ignore any headers related to 100rel extension.

Relay UPDATE

Transparent relay of SIP UPDATE between call legs.

Transit headers from origination

Filter of headers in SIP requests which applies to originated calls. Read more at headers filtering guide.

Transit headers from termination

Filter of headers in SIP requests which applies to terminated calls. Read more at headers filtering guide.

Sip interface name

SEMS interface to use for SIP communications. It might be useful to force specific IP address for SIP transport.

WARNING

SEMS interfaces should be properly configured , see SEMS signaling interfaces configuration

Contact userVariables supported

Defines the user part of the SIP Contact header. By default, Yeti-Switch builds the Contact header without a user part, for example:

Contact: <sip:192.0.2.4:5060;transport=udp>

When Contact userpart is specified, Yeti includes it in the Contact URI:

Contact: <sip:userpart@192.0.2.4:5060;transport=udp>

Use this option when the remote SIP endpoint requires a user portion in the Contact header for proper dialog handling or routing.

Signaling (Origination) attributes

Orig next hop

Network (IPv4 or IPv6) address or domain name that should be used as SIP next hop in case of using Gateway as Originator of calls. If this field doesn't specified - SIP next hop will be defined automatically by routing rules.

Orig append headers reqVariables supported

Additional SIP headers that Yeti should add to SIP requests to the Gateway (in case of using Gateway as Originator of calls). Additional header fields are lines composed of a header name, followed by a colon (😃, followed by a header value, and separated by newline.

Orig append headers replyVariables supported

Additional SIP headers that Yeti should add to SIP replies to the Gateway (in case of using Gateway as Originator of calls). Additional header fields are lines composed of a header name, followed by a colon (😃, followed by a header value, and separated by newline.

Orig route set

List of SIP URIs to use as Route set for Leg_A (origination side). Each entry must be enclosed in angle brackets, e.g. <sip:proxy.example.com;lr;transport=udp>. Multiple entries are applied in order as a preloaded Route set prepended to outgoing requests. See RFC 3261, Section 12.2.1.1.

Loose routing (lr parameter)

Include the lr parameter in each Route URI to enable loose routing (RFC 3261, Section 16.12). Without lr, strict routing (RFC 2543 behaviour) is used: the proxy replaces the Request-URI with its own address and appends the original Request-URI to the end of the Route list, which can cause interoperability issues with modern SIP stacks.

Transparent dialog

Not used yet.

Dialog nat handling

In case of enabling this field Yeti learns the proper remote address (port, transport,...) from the received message and uses that in following in-dialog requests. Enable this option when handling far end NATs.

Orig disconnect policy

Disconnect policy that is related to this Origination's attribute of the Gateway.

Incoming auth username

Username for additional username/password authentication of incoming requests if required.

Incoming auth password

Password for additional username/password authentication of incoming requests.

WARNING

It is strongly recommended to use build-in random generator for both username and password. You should not use usernames that looks like phone numbers.

WARNING

Incoming auth username and Incoming auth password will enable incoming INVITE and REGISTER requests username/password authentication procedure. INVITE request username/password authentication is additional step(after IP authentication) and it should be enabled by setting Customer Auth Require Incoming Auth flag. For REGISTER requests authentication applied automatically for all requests.

Incoming auth allow jwt

Allow JWT authentication mechanism to be used with this gateway.

Signaling (Termination) attributes

Settings in this sections only works when gateways acts as termination gateway for call.

Dump Level

Dump Level for call tracing mechanism. Read more in Troubleshooting Guide.

Transport protocol

Transport protocol that is used

SIP Schema

Specifies the URI schema used in the Request-URI, From, and To headers. Possible values:

sip

URI is built as sip:number@domain

sips

URI is built as sips:number@domain

sip with user=phone

URI is built as sip:number@domain;user=phone

INFO

See also: RFC3966, RFC4967

WARNING

In Yeti, using the sips schema does not automatically enable any encryption mechanisms. It only affects the URI generation logic.

HostVariables supported

IPv4 address, IPv6 address, or FQDN of the remote gateway used to send SIP signaling (termination only).
IPv6 addresses must be specified in IPv6reference format. See RFC2732, for example: [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]

Port

Port of the remote gateway used to send SIP signaling. If the port is specified, Yeti will not perform a DNS SRV lookup and will resolve the address using A / AAAA records only. Leave this field empty to enable DNS SRV resolution for the FQDN specified in Host.

Registered aor mode

Used for call termination to gateways with dynamic IP addresses. When enabled YETI sends call to R-URI received from remote UA(in Contact header) during registration procedure.

For incoming REGISTER request authentication YETI uses credentials specified in Incoming auth username and password fields.

Supported modes:

Do not use

feature disabled. INVITE will be sent do static IP/DNS name defined in Host

Use AOR as is

INVITE R-URI will be set to Contact received during registration procedure.

Use AOR, replace userpart with dst number

INVITE R-URI will be set to Contact, but user-part will be replaced with destination number. This mode is useful when remote system maintains single registration but expect to receive call to multiple DST numbers(in R-URI).

Network protocol priority

Yeti supports both IPv4 and IPv6 network protocols. When the Host gateway attribute contains an FQDN, the Network Protocol Priority setting allows you to control the preferred IP address family used for DNS resolution.
Available options:

Force IPv4

Resolves only A DNS records.

Force IPv6

Resolves only AAAA DNS records.

Any

Resolves both A and AAAA DNS records. The first available record is used.

Prefer IPv4

Resolves both A and AAAA DNS records. If at least one A record is available, it will be used.

Prefer IPv6

Resolves both A and AAAA DNS records. If at least one AAAA record is available, it will be used.

Resolve ruri

Indicates necessity to rewrite R-URI domain part with resolved IP.

For example: domain.com has IP 1.1.1.1 and you set Host to domain.com:

• resolve ruri enabled => RURI will be user@1.1.1.1
• resolve ruri disabled => RURI will be user@domain.com

Preserve anonymous from domain

When enabled, Yeti preserves the domain part of the From header as-is for anonymous calls, instead of replacing it with the gateway's domain. Useful when the termination gateway requires the original anonymous domain (e.g. anonymous.invalid) to be kept intact.

Auth enabled

Enable authorization for outgoing calls when remote peer require it(using 401 or 407 SIP responses)

Auth user

Username provided by remote peer.

Auth password

Password provided by remote peer.

Auth from user

Should be used for filling header "From" of SIP header during authorization (user part).

Auth from domain

Should be used for filling header "From" of SIP header during authorization (domain part).

Term route set

List of SIP URIs to use as Route set for Leg_B (termination side). Each entry must be enclosed in angle brackets, e.g. <sip:proxy.example.com;lr;transport=udp>. Multiple entries are applied in order as a preloaded Route set prepended to outgoing requests. See RFC 3261, Section 12.2.1.1.

Loose routing (lr parameter)

Include the lr parameter in each Route URI to enable loose routing (RFC 3261, Section 16.12). Without lr, strict routing (RFC 2543 behaviour) is used: the proxy replaces the Request-URI with its own address and appends the original Request-URI to the end of the Route list, which can cause interoperability issues with modern SIP stacks.

Term next hop for replies

When enabled, the address specified in Term next hop is also used for routing SIP replies (non-INVITE messages) in addition to initial requests. By default (disabled), replies follow standard SIP dialog routing.

Term next hop

Network (IPv4 or IPv6) address or domain name that should be used as SIP next hop in case of using Gateway as Terminator of calls. If this field doesn't specified - SIP next hop will be defined automatically by routing rules.

Term disconnect policy

Disconnect policy that is related to this Termination's attribute of the Gateway.

Term append headers reqVariables supported

Headers list to append to the requests sent by Yeti to termination gateway.

Sdp alines filter type

Filter type to process alines in SDP. possible values: Transparent, Blacklist, Whitelist.

Sdp alines filter list

SDP alines comma-separated list.

A-lines filtering mechanism allows to filter SDP A-lines received sent to gateway.

Ringing timeout

Timeout between 18x and 200 OK responses. In case of timeout: routing attempt will be canceled and further processing (attempt to reroute or give up) depends from disconnect policy.

Fake 180 timer

Allows to set up timer for 183 SIP messages with SDP. If there is no 183 message during this timer, SEMS would send 180 message forcibly.

Allow 1xx without to tag

Allows behavior, which violates RFC, when YETI will process 1xx responses without To-tag.

Force cancel routeset

When enabled, Yeti forces the complete route set to be used when sending a SIP CANCEL request.

Max 30x redirects

Amount of 301/302 SIP redirects that are allowed by Yeti for this Gateway (in case of using Gateway as Terminator of calls). Calls won't be redirected in case of filling this field by 0 (zero) value.

Max transfers

Amount of SIP transfers(using REFER mechanism) that are allowed by Yeti for this Gateway (in case of using Gateway as Terminator of calls). Calls won't be transferred in case of filling this field by 0 (zero) value.

Transfer append headers req

Additional SIP headers to include in outgoing REFER requests when performing call transfers via this gateway. One header per line. Useful for injecting tracking or routing headers specific to transfer scenarios.

Allowed methods

Overrides the list of SIP methods advertised in the Allow header of outgoing INVITE and UPDATE requests, and in 200 OK responses sent to this gateway. The Allow header informs the remote side which SIP methods Yeti supports in the context of this call. When empty, the built-in default is used: INVITE, ACK, BYE, CANCEL, OPTIONS, NOTIFY, INFO, UPDATE, PRACK. Available values: INVITE, ACK, BYE, CANCEL, OPTIONS, REGISTER, INFO, PRACK, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, PUBLISH.

Supported tags

Overrides the list of SIP extension tags advertised in the Supported header of outgoing INVITE and UPDATE requests, and in 200 OK responses sent to this gateway. The Supported header informs the remote side which optional SIP extensions Yeti is prepared to use in this dialog (for example, 100rel for reliable provisional responses or timer for session timers). Available values: 100rel, timer, replaces, path, outbound, gruu, norefersub, histinfo, tdialog, sec-agree, precondition, join, early-session.

Transfer tel uri host

When a termination gateway initiates a call transfer by sending a SIP REFER request with a tel: URI as the transfer target, Yeti cannot route the resulting INVITE without a host part. When this field is set, Yeti converts the tel: URI into a sip: URI by keeping the same user part and using this value as the host, making it possible to route the new INVITE.

Sip timer B

Overwrites the value of SIP timer B (transaction timeout). Call can be rerouted if this allowed by disconnect policy configuration.

Dns srv failover timer

SIP timer M (INVITE retransmit) override. Must have value less than timer B. Call can be rerouted if this allowed by disconnect policy configuration.

Suppress early media

Allows to send 180 Ringing message without SDP to LegA when received 180/183 with SDP from LegB of gateway.

Throttling profile

Optional Gateway Throttling Profile that controls automatic traffic reduction to this gateway based on error rate. See the throttling profile page for details on how the logic works.

Send lnp information

If enabled (in case of using Gateway as Terminator of calls) Yeti will include Local number portability information (LNP) to the outgoing INVITE-request (by adding npdi and rn parameters to the R-URI) only in case of availability of this LNP information (it means if LNP information was successfully received from LNP Database). Rules of receiving LNP information from LNP Database are regulated in the Routing plan LNP rules

Translations attributes

Privacy mode

Mode of privacy processing for calls terminated to gateway. Available options:

Do nothing

No special processing for private calls

Skip for private calls

gateway will be excluded from routeset during private call routing.

Skip for critical private calls

gateway will be excluded from routeset during private critical call routing.

Not trusted gw. Apply

Private call will be anonymized before sending call to gateway in order to hide private information.

Trusted gw. Forward

Private call will be sent to termination gw. PAI, PPI and From headers will not be anonymized.

Trusted gw. Forward. Anonymize From

Private call will be sent to termination gw, From header will be anonymized.

Termination SRC Numberlist

Optional Numberlist applied to the source number of calls routed to this gateway. If the source number matches a blocking entry, this gateway is skipped and routing continues to the next available gateway.

Termination DST Numberlist

Optional Numberlist applied to the destination number of calls routed to this gateway. If the destination number matches a blocking entry, this gateway is skipped and routing continues to the next available gateway.

Diversion send mode

Defines how to send Diversion header to termination gateway. Available options:

Do not send

Yeti will not send Diversion header

Send as SIP URI

Diversion value will be built as SIP URI

Send as Tel URI

Diversion value will be built as Tel URI

WARNING

• To send Diversion to termination gateway, Yeti should accept it first from call originator. See Customers Auth Diversion policy
• Diversion value sent to termination gateway will be stored to CDR attribute Diversion Out

Diversion domain

This setting allow to redefine domain part Diversion headers generated by Diversion Send mode logic when Yeti send it as SIP URI.

Diversion rewrite rule/result

Regular expression pattern to rewrite userpart of Diversion URI. See how to use POSIX Regular Expressions in Yeti.

PAI Send mode

Mode of P-Asserted-Identity header transmission to termination gateway. Available options:

Do not send

Do not send P-Asserted-Identity header

Build TEL URI from Source Number

Generate P-Asserted-Identity as tel URI header using Source number as user-part.

Build SIP URI from Source Number

Generate P-Asserted-Identity as sip URI header using Source number as user-part. PAI Domain should be defined.

Build SIP URI from Source Number with user=phone

Generate P-Asserted-Identity as sip URI with user=phone paramerer using Source number as user-part. PAI Domain should be defined.

Relay PAI/PPI as is

Relay P-Asserted-Identity and P-Preferred-Identity headers from call legA.

Relay PAI/PPI as TEL uri

Build P-Asserted-Identity and P-Preferred-Identity as tel URI based on P-Asserted-Identity and P-Preferred-Identity received from call legA.

Relay PAI/PPI as SIP uri

Build P-Asserted-Identity and P-Preferred-Identity as sip URI based on P-Asserted-Identity and P-Preferred-Identity received from call legA. If PAI and PPI headers received on legA have sip URI format, domain will be preserved. Otherwise PAI Domain will be used.

Relay PAI/PPI as SIP uri. Replace domain

Build P-Asserted-Identity and P-Preferred-Identity as sip URI based on P-Asserted-Identity and P-Preferred-Identity received from call legA. Domain part will be replaced with PAI Domain value.

WARNING

Relay PAI/PPI as TEL uri, Relay PAI/PPI as SIP uri, Relay PAI/PPI as SIP uri. Replace domain are experimental featured. Disabled by default.

WARNING

Modes that relays headers from call legA also require proper PAI Policy configuration at CustomersAuth object. P-Asserted-Identity and P-Preferred-Identity values sent to termination gateway will be saved in CDR attributes PAI Out and PPI OUT

PAI Domain

Domain part of P-Asserted-Identity and P-Preferred-Identity headers generated by PAI Send mode logic.

Src name rewrite rule

Regular expression pattern for From display-name part. See how to use POSIX Regular Expressions in Yeti.

Src name rewrite result

Regular expression replacement for From display-name part. See how to use POSIX Regular Expressions in Yeti.

Src rewrite rule

Regular expression pattern for From user part. See how to use POSIX Regular Expressions in Yeti.

Src rewrite result

Regular expression replacement for From user part. See how to use POSIX Regular Expressions in Yeti.

Dst rewrite rule

Regular expression pattern for To and RURI user part. See how to use POSIX Regular Expressions in Yeti.

Dst rewrite result

Regular expression replacement for To and RURI user part. See how to use POSIX Regular Expressions in Yeti.

To rewrite rule / To rewrite result

POSIX regular expression pair applied to the user part of the To header. Applied after all other destination number rewrites (dialpeer, termination numberlist, and gateway Dst rewrite rule/result) have completed — the input is the final rewritten destination number. The result affects only the To header; the RURI continues to use the destination number unchanged. See how to use POSIX Regular Expressions in Yeti.

Lua Script

Optional Lua script to execute custom call processing logic for calls terminated via this gateway. The script runs after number translation and can modify call attributes (numbers, headers, routing parameters). Lua scripts are managed in System → Lua Scripts.

WARNING

This feature is not functional yet.

Media Settings

SDP c location

The SDP c location parameter specifies the placement of the connection line (c=) in SDP payloads generated by Yeti. Possible values:

On media level

The connection line is included inside each media description (m= section).

v=0
o=yeti-switch 1122334455 1122334455 IN IP4 10.0.0.10
s=yeti-switch
t=0 0
m=audio 40000 RTP/AVP 0 8
c=IN IP4 10.0.0.10
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

On session level

A single connection line is included at the session level, applying to all media streams.

v=0
o=yeti-switch 1122334455 1122334455 IN IP4 10.0.0.10
s=yeti-switch
c=IN IP4 10.0.0.10
t=0 0
m=audio 40000 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

On session and media level

The connection line is present at both the session level and within each media description.

v=0
o=yeti-switch 1122334455 1122334455 IN IP4 10.0.0.10
s=yeti-switch
c=IN IP4 10.0.0.10
t=0 0
m=audio 40000 RTP/AVP 0 8
c=IN IP4 10.0.0.10
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

Codec group

Codecs group which will be used to interact with this gateway.

Proxy media

Determines RTP processing mode. Must be enabled to have possibility of transcoding.

Try avoid transcoding

When enabled, Yeti attempts to select a common codec between the origination and termination legs so that media can be relayed without transcoding. If no common codec is found, transcoding is used as a fallback. Reduces CPU load when successful. Requires Proxy media to be enabled.

Single codec in 200ok

The Single Codec in 200 OK option controls codec selection in SDP responses generated by Yeti.

When enabled

Yeti includes only one codec in the SDP answer.

• The selected codec is determined by the negotiated codec set for the gateway.
• The only exception is telephone-event, which is always added if it was present in the incoming offer and allowed in the gateway’s codec group.

When disabled

Yeti responds with the full set of negotiated codecs.

Force symmetric rtp

Ignore remote address negotiated in SDP. Use address gained from first received RTP/RTCP packet.

Symmetric rtp nonstop

By default, YETI allows to change address by symmetric RTP only one time. This option allows to disable this limitation. If enabled, YETI will change destination address every time when receives RTP/RTCP packet from another source.

Symmetric rtp ignore rtcp

When enabled, Yeti will not update or learn the remote RTP address from incoming RTCP packets. Only RTP packets will be considered for determining the remote address.

RTP Ping

The RTP Ping mechanism is designed to resolve situations where both gateways(origination and termination), operating with symmetric RTP enabled, are waiting for the first incoming packet before transmitting their own RTP stream.

When this option is enabled, Yeti proactively transmits a dummy (fake) RTP packet to the remote gateway immediately after the RTP stream initialization. This ensures that media exchange can be established even when both endpoints are configured to await the first packet.

RTP Timeout

The RTP Timeout parameter defines the maximum allowable interval without receiving RTP packets before a call is forcibly terminated. When the timeout condition is met, the call is disconnected, and the corresponding disconnect reason is recorded in the CDR.

Yeti applies a single RTP timeout value for both call legs. This value is computed as the maximum of origination_gateway.rtp_timeout and termination_gateway.rtp_timeout.

If the computed RTP timeout value equals 0, the timeout mechanism is disabled, and Yeti does not terminate calls in the absence of RTP packets.

WARNING

In SEMS versions prior to 1.170.1, the RTP Timeout is not reset upon the reception of RTCP packets. Beginning with version 1.170.1, SEMS behavior was updated: if RTCP packets are received, the call will not be disconnected even in the absence of RTP packets.

Filter noaudio streams

Cut all streams except of 'audio' from SDP in INVITE to the termination gateway. Appropriate non-audio streams will be automatically inserted as disabled (port set to zero) into responses to the gateway which sent offer to comply with RFC. Useful for gateways which processes multiple streams in SDP incorrectly or/and rejects INVITES with non-audio streams.

Rtp relay timestamp aligning

Normalize timestamp for RTP packets on RTP relay. Useful for cases on RTP relay when remote side changes RTP streams without appropriate signaling (RTP mark or/and re-INVITE) and destination equipment is not ready to process such behavior correctly.

Rtp force relay CN

If enabled, YETI will relay Comfort Noise packets on even if they were not negotiated in SDP.

Force one way early media

If this checkbox is enabled Early Media (the ability of two SIP User Agents to communicate before a SIP call is actually established) will be blocked on the way from LegA (Originator) to LegB (Terminator) of the call. It helps to prevent fraud with using Early Media features for making non-billed calls.

Rtp interface name

Allows to force Media interface that will process RTP traffic from/to gateway. Interface with such name should be defined at SEMS media interfaces configuration

Media encryption mode

Defines RTP encryption mechanism, possible values:

Disable

Plain RTP will be used(no encryption).

SRTP SDES

SRTP with SDES key negotiation mechanism. In this mode SRTP keys will be sent in SIP SDP payload so it is important to secure SIP signalling by TLS or other secure transport.

SRTP DTLS

SRTP with DTLS key negotiation mechanism. DTLS is RTP inband mechanism and it doesn't require secured SIP signalling.

SRTP ZRTP

SRTP with ZRTP key negotiation mechanism. ZRTP is not standard but sill widely used.

INFO

SEMS should be properly configured to support SRTP, see SEMS media interfaces configuration

Depending on the RTCP Feedback Mode setting, different RTP profiles may be used:

Media encryption mode	RTCP Feedback Mode	Allowed RTP Profiles for incoming SDP Offer	RTP Profile for outgoing SDP Offer
Disable	Disabled	RTP/AVP	RTP/AVP
Disable	Accept	RTP/AVP, RTP/AVPF	RTP/AVP
Disable	Initiate	RTP/AVP, RTP/AVPF	RTP/AVPF
SRTP SDES	Disabled	RTP/SAVP	RTP/SAVP
SRTP SDES	Accept	RTP/SAVP, RTP/SAVPF	RTP/SAVP
SRTP SDES	Initiate	RTP/SAVP, RTP/SAVPF	RTP/SAVPF
SRTP DTLS	Disabled	UDP/TLS/RTP/SAVP	UDP/TLS/RTP/SAVP
SRTP DTLS	Accept	UDP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF	UDP/TLS/RTP/SAVP
SRTP DTLS	Initiate	UDP/TLS/RTP/SAVP, UDP/TLS/RTP/SAVPF	UDP/TLS/RTP/SAVPF
SRTP ZRTP	Disabled	RTP/AVP	RTP/AVP
SRTP ZRTP	Accept	RTP/AVP, RTP/AVPF	RTP/AVP
SRTP ZRTP	Initiate	RTP/AVP, RTP/AVPF	RTP/AVPF

ICE Mode

Interactive Connectivity Establishment(ICE) operation mode. Read more at RFC8445. Possible options:

Disabled

ICE SDP attributes will be ignored, ICE negotiation will not be performed, system will behave as if ICE is not supported.

Accept

ICE mechanisms will be enabled if ICE SDP attributes are present in the incoming SDP Offer. Outgoing SDP Offers will not contain ICE attributes. LegB for calls terminated to such gateway will not use ICE mechanisms to negotiate the media path.

Initiate

ICE mechanisms will be enabled if ICE SDP attributes are present in the incoming SDP Offer. Outgoing SDP Offers will also contain ICE attributes.

RTCP Mux Mode

This attribute controls behavior of the RTCP Multiplexing mechanism. Read more at RFC5761.
Possible options:

Disabled

RTCP Multiplexing will be disabled. SDP offers and answers sent by the system will not contain the a=rtcp-mux attribute.

Accept

RTCP Multiplexing will be enabled if it requested in the incoming SDP Offer. Outgoing SDP Offers will not request RTCP Multiplexing — no a=rtcp-mux attribute will be sent.

Initiate

RTCP Multiplexing will be enabled if it requested in the incoming SDP Offer. Outgoing SDP Offers will request RTCP Multiplexing as well — the a=rtcp-mux attribute will be sent.

RTCP Feedback Mode

This attribute controls behavior of the RTCP Feedback mechanism. Read more at RFC8888.
Possible options:

Disabled

RTCP Feedback will be disabled.

Accept

RTCP Feedback will be enabled if requested in incoming SDP Offer (by using F RTP Profile). Outgoing SDP Offers will not use the F RTP Profile.

Initiate

RTCP Feedback will be enabled if requested in incoming SDP Offer (by using F RTP Profile). Outgoing SDP Offers will use the F RTP Profile.

INFO

RTCP Feedback Mode and Media Encryption mode settings affect RTP Profile negotiation. See Media Encryption mode description for details.

TIP

Media Encryption Mode, ICE Mode, RTCP Mux Mode, and RTCP Feedback Mode settings require specific configuration to enable WebRTC. Read more in Yeti WebRTC documentation.

RTP Acl

List for networks where RTP receiving allowed from. Example: 10.20.30.0/24, 192.168.0.0/16

DTMF attributes

DTMF data-path displayed on diagram:

WARNING

This diagram is not represent internal processing implementation. This is just explanation of DTMF-related behavior of Yeti-Switch depends on gateway configuration.

WARNING

To receive/send DTMF using RTPEvent mechanism appropriate payload type should be negotiated first.

• Ensure telephone-event payload present in codec group.
• Ensure telephone-event payload correctly negotiated with remote gateway after SDP offer/answer procedure.

Force dtmf relay

Relay telephone-event (RFC2833) packets 'as is' to other leg. DTMF relay mechanism is deprecated and should not be used.

Dtmf send mode

The way to send dtmf to remote gateway. possible values:

Disable sending

Do not send DTMF

RFC 2833 (telephone-event)

Send DTMF in telephone-event format

SIP INFO application/dtmf-relay

Send SIP INFO requests with Content-Type: application/dtmf-relay

SIP INFO application/dtmf

Send SIP INFO requests with Content-Type: application/dtmf

Dtmf receive mode

Allowed ways to receive DTMF from remote gateway. If the way is not allowed it will be ignored. Possible values:

• RFC 2833 (telephone-event)
• SIP INFO application/dtmf-relay OR application/dtmf
• RFC 2833 OR SIP INFO
• Inband
• Inband OR RFC 2833

Rx inband dtmf filtering mode

Could be used for to remove inband DTMF signals (DTMF audio tones in the RTP stream) in the incoming RTP-flow that is received from this gateway. Could have following values:

Inherit configuration from other call's leg

Tx inband dtmf filtering mode value from the gateway that is associated with other call leg will be used. F.e. for termination Gateway - value from origination Gateway will be used.

Disable

DTMF signals will be ignored and will be forwarded as is.

Remove DTMF

DTMF signals will be replaced by "silence" signal in the incoming RTP-flow that is received from this gateway.

Tx inband dtmf filtering mode

Could be used for setting mode of processing of the inband DTMF signals (DTMF audio tones in the RTP stream) in the outgoing RTP-flow that will be sent to this Gateway. Could have following values:

Inherit configuration from other call's leg

Rx inband dtmf filtering mode value from the gateway that is associated with other call leg will be used. F.e. for termination Gateway - value from origination Gateway will be used.

Disable

DTMF signals will be ignored and will be forwarded as is.

Remove DTMF

DTMF signals will be replaced by "silence" signal in the outgoing RTP-flow that will be sent to this Gateway.

INFO

Rx/Tx inband dtmf filtering features are useful when it necessary to remove DTMF transmission, or when remote Gateway sends DTMF to both inband and as RTP-event simultaneously. Enabling the corresponding function will remove duplicate information from inband.

WARNING

Rx/Tx inband dtmf filtering affects CPU utilization and should be enabled with care.

Radius attributes

Radius accounting profile

Radius accounting profile that is related to this Gateway. When profile attached to gateway, accounting data related to call leg will be sent to RADIUS server.

STIR/SHAKEN attributes

STIR/SHAKEN mode

Controls whether Yeti adds or relays an Identity header when sending the call to this termination gateway. The result is recorded in LegB SS Status. Possible values:

Disable

No Identity header is added to the outgoing INVITE. LegB SS Status is None.

Relay or insert (routing numbers)

If LegA SS Status is valid (A, B, or C), the original Identity header is relayed unchanged and LegB SS Status equals LegA SS Status. Otherwise, if an attestation level is available (from Rewrite SS Status on Customer Auth or Numberlist Item configuration) and a STIR/SHAKEN crt is configured, Yeti signs a new identity using the routing numbers (Src Prefix Routing / Dst Prefix Routing) and sets LegB SS Status to that level.

Relay or insert (output numbers)

Same relay/insert logic as above, but the new signature uses the output numbers (Src Prefix Out / Dst Prefix Out) instead of routing numbers.

STIR/SHAKEN crt

STIR/SHAKEN certificate to use for Identity signing when inserting a new Identity header.

WARNING

STIR/SHAKEN mechanisms are disabled by default.