Ydiameter

From Yate Documentation
Jump to: navigation, search

NOTE: This module is available in private version only.

Contents

Commands

status [overview] diameter [{{node|peer node_name|listener|conn|session} name}|allnodes|allpeers|alllisteners|allconns|allsessions]

Report diameter status.
Report specific entity's status if requested.

diameter showstats [{node|peer node_name|listener|conn} name]

Verbose output diameter statistics.
Report specific entity's statistics if requested.

diameter drop {node|peer node_name|session|conn} name

Drop specified entity.
This command should be used with extreme caution.
NOTES:

  • Dropping a node will also drop all its peers and connections
  • Dropping a peer will terminate its connection (transport)
  • When a node or peer is dropped its statistics are lost. Global statistics are not lost: they will include dropped entity's statistics.

Features

Fake a response when a request fails to be sent

This feature allows the module to generate a message faking a response when a request fails to be sent (in message handler or subsequent failure).
Message parameters:

  • local_failure_response: Instructs the module to generate a response.
    A boolean true value will use a message name derived from request application id. Any other non empty string will be used as message name.
    If handled message has a route_prefix parameter indicating a relayed request this parameter will default to diameter if missing.
    NOTE: If the parameter is present but empty no response will be faked, the module will generate a local error message on failure
  • local_failure_response_async: Asynchronously generate protocol error XML when failed to send in message handler (defaults to configured).
    If disabled, generated response XML will be returned in handled message response parameter
  • local_failure_error: Optional Diameter result code to set generated response. Defaults to UNABLE_TO_DELIVER
  • local_failure_error_message: Optional, boolean: true to add ErrorMessage text to generated response
  • recv_node: Optional node (realm/host) to set in OriginRealm/OriginHost AVPs

Altering Diameter commands, routing, returning parameters

This feature is used to route and alter sent commands, alter received responses and return parameters in yate messages.
This is handled when a non empty parameter route_prefix or message_prefix is found

  • route_prefix: Indicates a relayed command. This parameter should be used by Diameter relay/routing agent (a request received by Diameter is relayed/routed to Diameter).
    If the command is a request the response's yate message will contain a proxied=true parameter to allow diameter module to handle it back.
    NOTE: If present message routing parameters (like local_node and remote_host) MUST be prefixed with it
  • message_prefix: Message routing parameters are taken from handled message, not prefixed.

All parameters listed below are handled if they start with the indicated prefix.

Parameters applied when command is sent:

  • add_avps
    Contains a string with an XML fragment with AVPs to be added to the command
  • hide_network_topology_avps
    Remove network topology related AVPs from command: RouteRecord, ProxyInfo.
    ProxyInfo AVPs will be restored when a response is received (they will be added to the response xml)
  • route_record
    If not empty add a RouteRecord AVP to sent command.
    This parameter should be used for requests only. It is useless in responses.
  • proxy_host and proxy_state
    These parameters instructs the module to add a ProxyInfo AVP to sent command.
    These parameters are used for debug purposes only: added AVP will be removed from received response

NOTE: These parameters are handled in the order they appear in handled message

Parameters applied when command send result is handled:

  • orig_hhident Restore (set) the Hop-By-Hop Identifier
  • orig_eeident Restore (set) the End-To-End Identifier

All parameters starting with answer. will be automatically copied to yate message sent when request result is handled.

proxied parameter

This is boolean parameter set in yate messages.
When a message is not proxied (the parameter is not set to boolean true) the module will check/add:

  • OriginHost and OriginRealm AVPs
  • AuthApplicationId or AcctApplicationId or VendorSpecificApplicationId if required by command description
  • Request:
    • Generate End-To-End Identifier
    • Generate SessionId and AuthSessionState if required by command description
  • Answer:
    • Add SUCCESS ResultCode if ResultCode or ExperimentalResult are missing and required by command description

Incoming transaction tracking

Incoming transaction tracking is done by setting transaction_ttl to non 0 value.
When enabled a trans_id parameter is added to yate messages sent by diameter module.
As long as transaction lives subsequent requests with the same OriginHost and End-To-End Identifier will be handled internally. They will receive the same response. The module will dispatch a single yate message for the first transaction request.
Behaviour:

  • ProxyInfo AVPs are retained by the module, they won't appear in attached xml. Proxy info data will be returned by transaction for each handled request
  • Transaction response may be sent when initial message is handled or in subsequent message
  • When the response is sent in subsequent message it MUST carry the trans_id parameter
  • When a response is returned to a tracked transaction there is no need to return the following attributes/AVPs:
    • Attributes: hhident, eeident
    • AVPs: SessionId, AuthSessionState, OriginHost, OriginRealm
  • If the response don't contain OriginHost its origin will be set to the node receiving the first transaction request

NOTE: This feature should be enabled when processing application is local and disabled when module is running with a routing agent. For a routing agent this option should be disabled: if the first request fails to be forwarded all other requests will fail also

Selecting a local node and peer to send a command

This section describe the procedure used to select a local node and a peer to send a command (assuming it wasn't a response for a tracked transaction and a connection id was not given).

  1. Try local_node parameter.
    If a node is found try sending the message using this node.
    Go to (2) on failure.
  2. Try default or alternate node. These options are mutually exclusive: if alternate node parameter is non empty default node(s) won't be checked
    1. Try alternate_node_prefixes if the command is a request.
      This is a comma separated list of prefixes. Each prefix (alternate_node + prefix) indicates a set of parameters (local node/peer) to use to send the command.
    2. Try configured default node(s) if the command is a request: per realm (if local_node is present) and global. Per realm default is checked first.
      Default node usage may be disabled by check_default_node_realm and check_default_node_global parameters

Alternate node message parameters example:

alternate_node_prefixes=node1_,node2_
alternate_node_node1_local_node=example.com/dra.example.com
alternate_node_node1_remote_host=example.com/hss.example.com
alternate_node_node2_local_node=example.com/dra1.example.com
alternate_node_node2_remote_host=example.com/dra2.example.com

For each local node check the remote_host parameter:

  • Command is a request: Check for a connection with peer indicated in remote_host
    If a connection is not found check peers with default route priority set and use them to send the request.
  • Command is an answer: Identify a connection with required peer and use it to send the command.
    No alternate peer is used: answers MUST be sent hop by hop (i.e. we MUST use the same peer to send an answer).

Election

The election process is used when an incoming connection is going to be accepted.
The library will check for an outgoing connection to the same remote peer host.
If the local host is greater then remote host the incoming connection is refused with diameter error 4003 (ELECTION_LOST).
If the remote host is greater then local host the outgoing connection is closed.

Decoding and encoding of unknown AVPs

Unknown AVPs are marked by an xml tag starting with AVP_ folowwed by AVP code.
A received unknown AVP will be dumped in xml text: Here is an example of AVP with code=2, vendor flag set and vendor id 200:

<AVP_2 flags="vendor" vendor="200">0f000000<AVP_2>

An unknown AVP may be encoded. An AVP format may be indicated:

<AVP_2 flags="vendor" vendor="200" format="uint32">15<AVP_2>

It is not possible to use this method to encode a known AVP. E.g. for the following code (1: Username, format: utf8string) with vendor 0 (Diameter Base Protocol) the format attribute will be ignored, the xml text will be interpreted as UTF8 string:

<AVP_1 format="uint32">15<AVP_1>

The AVP format may be: octetstring (default if missing or invalid), int32, int64, uint32, uint64, grouped, address, time, utf8string, diameterident, diameteruri, enumerated. The following diameter AVP formats are not currently supported: float32, float64, ipfilterrule, qosfilterrule.
When encoding an unknown AVP:

  • XML text must not be empty for non grouped AVPs
  • A grouped AVP must have children AVP (known or unknown)
  • If the format indicates octetstring the xml text must be a hexified string
  • The following formats are equivalent: utf8string, diameterident
  • The address format must carry a valid IPv4 or IPv6 address
  • The time format must carry UNIX time in seconds
  • diameteruri format: The XML may contain the URI in its text or may carry a host attribute. The following attributes are optional: secure (defaults to false), port, transport, protocol. As an alternative the AVP text may be set, in which case the URI attributtes will be ignored.

Decoding and encoding of unknown commands

Commands with unknown codes are always encoded.
To accept decoding of unknown commands the parseunkcmd flag must be set in codec_options.
If not set the unknown request will be rejected with Diameter error 3001 (COMMAND_UNSUPPORTED).
The xml set in enqueued message will have a tag starting with "CMD_" followed by command code:

<CMD_3 flags="request" appid="15">
  <OriginHost>some.host</OriginHost>
  <AVP_2 flags="vendor" vendor="200">0f000000<AVP_2>
</CMD_3>

Decoding and encoding of unknown applications

Messages with unknown applications are always encoded.
To accept decoding of unknown applications the parseunkapp flag must be set in codec_options.
If not set the unknown request will be rejected with Diameter error 3007 (APPLICATION_UNSUPPORTED).
The xml set in enqueued message will have a tag starting with "CMD_" as described in Decoding and encoding unknown commands.

Query

Module may be queried using the diameter.query message.
Query target is handled using the operation parameter with the following values:

pending_reqs

Query connections for pending requests (not sent or already sent waiting for response).
Parameters:

  • query_params: Message parameter containing the Diameter request parameter to match.
    If this parameter is empty the module will set result to true if there is any request pending
  • param_name=value: Optional parameter to match in pending requests

Query result will be set in result parameter as boolean value.
Query will fail if query_params is not empty and indicated parameter is not found in message.

Statistics

The following layers can update statistics:

  • Connection: Transport layer
  • Peer: A node's peer (holds a connection)
  • Node: A specific local identity
  • Diameter: Global

The statistics are reported by status diameter or diameter showstats.
Connection layer statistics are pushed up to peer -> node -> global.
Peer layer statistics are pushed up to node -> global.
NOTE: Diameter commands counters doesn't include commands used to negotiate, maintain or terminate a connection (e.g. CER/CEA, DWR/DWA, DPR/DPA)

Connection (transport) layer

  • recv_messages: Total number of diameter commands dequeued from parser queue
  • recv_requests: Number of received diameter requests
  • recv_answers: Number of received diameter answers
  • sent_messages: Total number of sent diameter commands (successfully wrote to socket)
  • sent_requests: Number of sent diameter requests
  • sent_answers: Number of sent diameter answers
  • rejected_messages: Number of requests rejected at connection layer. Possible reason: unsupported command, application, unsupported protocol version
  • detected_loops: Number of detected loops (for incoming requests)
  • message_timeouts: The number of timed out requests (no answer received)
  • unexpected_answers: The number of received answers for which diameter don't hold a request (answer dropped)
  • route_failed: The number of failed to route requests. This is the number of sent answers with Result-Code set to 3002 (unable to deliver) or 3003 (realm not served). Answers carrying those result codes received by Diameter (not locally generated) are not counted here
  • conn_attempt_out: Number of outgoing connect attempts
  • conn_failed_out: Number of failed outgoing connect attempts

Peer layer

  • All connection layer statistics
  • failed_messages_conn: The number of diameter commands failed to be sent after enqueued in a connection
  • failed_requests_conn: The number of failed diameter requests (after enqueued in a connection)
  • failed_answers_conn: The number of failed diameter answers (after enqueued in a connection)

Node layer

  • All connection layer statistics
  • All peer layer statistics

Listener

  • conn_attempt_in: Number of incoming connection attempts
  • conn_failed_in: Number of failed incoming connections (failed to create the internal structure to negotiate the connection)

Global

  • All connection layer statistics
  • All peer layer statistics
  • All node layer statistics
  • All listeners statistics
  • failed_messages: The number of diameter commands Diameter failed to be enqueued in a connection
  • failed_requests: The number of failed diameter requests
  • failed_answers: The number of failed diameter answers

Diameter identity (local node parameters)

NOTE:
All node parameters MUST be the same when updating a node (in user.login or user.register return)
There is no way to predict the order of node update

A Diameter node is identified by a local node and realm.
The module will dynamically create or update local nodes when an outgoing connection is created or an incoming one is authorized.
Local node id used in messages handled or sent by the module is built from realm and host.
E.g. for realm 'localrealm.com' and host 'localhost.localrealm.com' the node id will be 'localrealm.com/localhost.localrealm.com'.

Local node parameters:

  • local_node: Local node identity: realm/host.
  • default_realm_priority: integer: Optional per realm default node priority to be used to pick this node when requested node (indicated in command send request) is not found
  • default_priority: integer: Optional global default node priority to be used to pick this node when requested node (indicated in command send request) is not found
  • product_name: Required product name (string) to advertise to remote party. Defaults to 'YATE/${version}'.
  • firmware_revision: Product firmware revision (unsigned integer) to advertise to remote party. Defaults to '${revision}'.
    This parameter is optional, set it to '0' if you don't want to be sent.
  • hostipaddr: Comma separated list of IP addresses to be advertised to remote party.
    Connections will advertise local address(es) of their socket if this parameter is empty.
  • ssl_context: SSL context to use for incoming connections.
    This parameter is used when inband security (TLS) is negociated on an incoming connection.
    If not set the connection will use its local node realm as domain in socket.ssl message.
  • apps: Comma separated list of supported applications.
    A vendor id may be added after application id. It is not necessary to add it if the application is known by the module.
    E.g.: apps=16777252,1234/1000
    The first item indicates known application 16777252 (vendor 10415).
    The second item in the list indicates application 1234 for vendor 1000.
  • role: Keyword. Values: node,relay. Set node role. This parameter is handled when a new node is created.
    • node: Default value. Node is a client and/or server Diameter agent
    • relay: Enforce relay (0xffffffff) application support. The apps parameter may not be set. For relay nodes the module will send diameter messages instead if diameter.appid
  • redirect_max: integer: Optional counter for allowed redirects. Set it to 0 (default) to disable redirect handling. Global value (see configuration file) is used if this parameter is not set
  • create_dynamic_peers: boolean: Create a peer if unknown when handling a redirect indication. Defaults to no.

NOTES:
- The above parameters, except for 'local_node' will be used to update a local node from each message used to create, update or authorize a connection.
- They are applied for new connections only.

Outgoing connections

Outgoing connections are setup using the 'user.login' message.
The protocol parameter must be set to diameter.

Creating or updating an outgoing connection
The message operation parameter must be 'login'.
Handled parameters:

  • local_node: Local node to create/update and use
  • remote_host: Remote (peer) Diameter host identity. The connection will be closed if the remote party will advertise a different host when exchanging capabilities.
  • address: Remote address to connect to. Required if server is not set. For 'sctp' transport it may be a comma separated list of addresses
  • server: Remote server to connect to. If set NAPTR/SRV will be used to discover connect address and transport if not disabled by configuration.
  • port: Port to connect to. Used only if 'address' or 'server' are set in conjuction with 'transport'. If a transport is set port will default to 3868 for sctp/tcp and 5658 for tls.
  • transport: Optional transport. Allowed values are 'sctp', 'tcp', 'tls'. Defaults to 'sctp' if NAPTR/SRV are disabled or not available.
  • localip: Optional local address to bind on. For 'sctp' transport it may be a comma separated list of addresses
  • localport: Optional local port to bind on

The following parameters from ydiameter.conf can be overridden in user.login:

  • conn_options
  • bind_reuse

The message may contain parameters used to update local node data (see local node parameters).

Deleting an outgoing connection

An outgoing connection is deleted when handling an user.login message with operation=logout.
NOTE: If an incoming connection was received and accepted from the peer set when the outgoing connection was setup (e.g. a connect collision was resolved in favor of remote peer's connection) the connection data related to static config parameters set in user.login will be reset.

Authorizing incoming connections

Incoming connections can be authorized by handling the user.register message.
On return, the message will create/update a local node also.

Message parameters:

  • protocol: diameter
  • connection_id: Connection id (e.g. diameter/1)
  • data: Module and connection id. (e.g. diameter/diameter/1)
  • localip: Connection local IP address
  • localport: Connection local port
  • remote_realm: Advertised remote realm
  • remote_host: Advertised remote host
  • remote_apps: Advertised applications (comma separated list)
  • ip_host: Connection remote IP address
  • ip_port: Connection remote port
  • productname: Advertised product name
  • productrevision: Advertised product revision
  • transport: Connection transport (sctp/tcp/tls)

When the incoming connection will terminate the module will enqueue an user.unregister message with the following parameters:

  • data: Module and connection id. (e.g. diameter/diameter/1)

Generating requests

To generate (send) a diameter message a module must send a message whose name is built from message application. E.g. for 3GPP S13 interface the message name must be diameter.16777252.

Message parameters:

  • oconnection_id: Connection to use to send the message
  • local_node: Local node used to send the message (required if oconnection_id is missing)
  • remote_host: Remote host to send the message to (required if oconnection_id is missing)
  • timeout: Optional request timeout in milliseconds
  • xml: This parameter will carry the message to be sent (XmlElement object or xml string)

NOTES:

  • The oconnection_id will override local_node and remote_host. If no connection is found message send will fail.
  • It is recommended to avoid using the oconnection_id to indicate a connection: the remote peer may be a relay/redirect agent (advertised when supporting the application with id 4294967295) and may redirect the request. This may generate extra traffic.
  • Use oconnection_id if the remote peer is not a relay/redirect agent and it can't connect to yate (there are no listeners available to it)

When a request is succesfully enqueued in connection's send queue the module will:
- Generate an End To End Identifier for the request. Its value will be returned in eeident message parameter. The sender must use it to match the answer.
- Generate a session id for requests requiring it (if not already set by the sender). If a session id is generated the module will set it in session_id parameter of the handled message.

Request send may fail (due to remote application support change, connection failure ...) or the request may time out.
The module will then enqueue a message indicating failure. The message will contain a localerror parameter (timeout/failure) to indicate local failure. It will also contain eeident and session_id parameters also along with request xml.

Here is an example of XML element:

<MEIdentityCheckRequest appid="16777252" flags="request,proxiable">
  <DestinationRealm>realm.com</DestinationRealm>
  <TerminalInfo vendor="10415">
    <IMEI vendor="10415">1234567890</IMEI>
  </TerminalInfo>
</MEIdentityCheckRequest>>

Generating answers

Answers can be generated in handled message or in a separate one.
The answer xml can be set in handled messages's response parameter.

Answer example:

<MEIdentityCheckAnswer appid="16777252" hhident="${hhident}" eeident="${eeident}">
  <SessionId>${session_id}</SessionId>
  <AuthSessionState>1</AuthSessionState>
  <EquipmentStatus vendor="10415">whiteListed</EquipmentStatus>
</MEIdentityCheckAnswer>

NOTES:

  • When an answer is generated using a separate message the message must indicate the routing info: oconnection_id or local_node/remote_host.
  • When generating an answer the following request attributes MUST be sent back: hhident, eeident.
  • For requests carrying a session id this AVP must be sent back also.

Return answers in the message carrying the request

  • Set an xml with response in the response parameter
  • Return an error by setting a respond parameter to boolean true (the respond parameter defaults to true if the message is not handled, i.e. the handler returns false).

The error is handled using the following algorithm:

  • Check for a vendor_error parameter (if present it must have the format: error_code/vendor_id, e.g. "5001/10415" for 3GPP user-unknown error). The answer will return it in ExperimentalResult AVP.
  • Check for a Diameter base protocol error code in the message error parameter

NOTES:

  • If a Diameter base protocol error code is given and is not a protocol error code (protocol errors range is [3000..4000)) a force-non-proto-error=true must be set to force sending the answer. The reason is the module can't know how the response to a specific request should look like: the responding entity must know what it's doing when forcing non protocol error send.
  • For both methods of returning the response the message may contain an extra failedavp parameter containing the failed AVP(s). The parameter may contain an XmlElement or an xml string which may be an xml element or an xml fragment.

Handling messages sent by Diameter module

When receiving a request or answer the module will enqueue a message whose name is built from request/answer application. E.g. for 3GPP S13 interface the message name will be diameter.16777252.
NOTES:

  • For relay nodes the module sends a diameter message

Message parameters:

  • module: diameter
  • connection_id: Connection receiving the Diameter message
  • local_node: Local node receiving the Diameter message (realm/host)
  • local_realm: Local realm receiving the Diameter message
  • local_host: Local host receiving the Diameter message
  • local_relay: Request only. Boolean true if the connection advertised relay application support
  • remote_host: Request only. Connection remote host advertised during capabilities exchange
  • remote_realm: Request only. Connection remote realm advertised during capabilities exchange
  • origin_host: Request only. Request origin host AVP if not the same as connection remote host
  • origin_realm: Request only. Request origin realm AVP if not the same as connection remote realm
  • destination_host: Request only. Destination host AVP if present
  • destination_realm: Request only. Destination realm AVP if present
  • type: Diameter command type:
    • request: The message carries a Diameter request
    • answer: The message carries a Diameter answer
    • error: The message carries a Diameter answer with error flag set (protocol error)
    • localerror: The message carries a Diameter message that failed to be sent or timed out
  • operation: Diameter message name (e.g. UpdateLocationRequest, UpdateLocationAnswer ...)
  • operation_short: Diameter message short name (e.g. ULR, ULA ...)
  • localerror: Local failure error (for type=localerror): timeout or failure
  • Diameter message fields: code, appid, flags, hhident, eeident
  • parser_error: Optional. Contains the first parser error code
  • parser_notice: Optional. Comma separated list of various parser notifications
    • error: Parser encountered an error
    • unkavp/unkavp-mandatory: Found at least one unknown AVP (with M-bit set)
    • p-bit-avp: Found an AVP with P-bit set
    • cmd-unk-flags: Command contains unknown flags
    • avp-unk-flags: Command contains at least one AVP with unknown flags
  • session_id: Optional Diameter message session id AVP
  • xml: Received Diameter message

For requests the flags parameter will contain request and may contain proxiable. E.g. flags="request,proxiable" or flags="request" (for non proxiable requests).
For answers the flags parameter will not contain request and may contain error or proxiable. E.g. flags="" or flags="proxiable" (for answers to proxiable requests) or flags="error".
If the an answer's flags contain error this indicates protocol error, don't try to check for expected AVPs in the response. The handler may look at the ResultCode AVP.

Supported applications

  • Credit-Control Application
  • 3GPP S6a/d Interface
  • 3GPP S13 Interface
  • 3GPP Cx/Dx Interface

Configuration

Configuration file is ydiameter.conf

; Configuration file for Diameter module
; Unless explicitly specified, all parameters are applied on reload

[general]

; relay_default_route: integer: Default route priority for peers advertising relay
;  application support
; Set it to negative value to disable automatic set of default route priority for peers
;  advertising relay
; This value is ignored if connection default route priority is set when created or accepted
; Defaults to 100
;relay_default_route=100

; local_failure_response: boolean/string: Generate (fake) XML with diameter protocol error
;  when a request failed to be sent (local failure)
; This parameter can be overridden in handled messages
; For relayed requests configured parameter value is ignored. It is taken from handled message and
;  defaults to 'diameter'
; Values:
;  boolean true: Fake using handled message's application id (diameter.appid_value)
;  any other string: Fake using indicated message
;  empty: disable
;local_failure_response=

; local_failure_response_async: boolean: Asynchronously generate protocol error XML when
;  failed to send in message handler
; This parameter can be overridden in handled messages
; If disabled, generated response XML will be returned in handled message 'response' parameter
; Defaults to no
;local_failure_response_async=no

; conn_options: string: Comma separated list of connection options
; The flags will control the behaviour of a connection
; This parameter is applied on reload for new connections only
; Allowed values:
;  nonaptr: Outgoing, don't use NAPTR query to descover the address to connect
;  nosrv: Outgoing, don't use SRV query to descover the address to connect
;  norestart: Outgoing: don't restart when connection is lost
;  rfc6733: RFC 6733 compliant
;  noredirect: Don't handle redirect indication answers
;  tlsrequired: TLS is required for the connection
;    RFC 6733 enabled:
;      Outgoing: this flag is used only when processing NAPTR records to filter
;                TLS transports
;      Incoming: this flag is ignored, no inband security can be negotiated
;    RFC 6733 not enabled:
;      Incoming: this flag is ignored for non TCP connections (inband security can
;                be negotiated for plain TCP connections only)
;conn_options=

; codec_options: string: Comma separated list of codec options
; The flags will control the behaviour of the parser
; This parameter is applied on reload for new connections only
; Allowed values:
;  parseunkapp: Parse received messages with unknown application id
;    If not set, messages with unknown application id will be dropped/denied
;  parseunkcmd: Parse unknown commands with known application id
;    If not set, unknown messages will be dropped/denied
;  checkavpflags: Check AVP flags. This flag is ignored for relay nodes
;    Check sent/received AVP flags that must be set and flags that must not be set
;    If flags check fails the AVP will not be built/parsed
;  stopencodefail: Stop on AVP encode failure
;    If not set message encoding will continue after AVP encode failure
;    This flag is not used for mandatory AVPs: a mandatory AVP may appear more then
;     once and all its instances fail then message encode will fail
;  relaxed: Run in relaxed mode. Some behaviour changes:
;    Parse unknown commands/apps
;    Ignore AVP occurences (min/max bounds) when encoding
;    This flag should be used for debug purposes only: it will allow the module
;     to generate invalid messages
;  relayforceappcheck: Force application id check for relay nodes
; NOTES:
; - parseunkapp and parseunkcmd are automatically set for connections advertising
;   relay or unknown applications
;codec_options=

; force_protocol_error: boolean: Force protocol error flag for permanent failures
;  responses built by module
; NOTE: this is allowed by RFC 6733 and not allowed by RFC 3588
; Defaults to yes. If disabled, automatically built responses with non protocol errors
;  will change error to UNABLE_TO_DELIVER
;force_protocol_error=yes

; request_timeout: integer: Timeout, in milliseconds, of a sent request
; This parameter can be overridden by a 'timeout' parameter
; Minimum allowed value: 1000
; Defaults to 60000
;request_timeout=60000

; connect_timeout: integer: Timeout, in milliseconds, of an outgoing connection attempt
; Interval allowed: 1000..120000
; Defaults to 60000
;connect_timeout=60000

; connect_interval: integer: Interval, in milliseconds, to re-connect an outgoing
;  connection
; Interval allowed: 1000..300000
; Defaults to 30000
;connect_interval=30000

; dwr_interval: integer: Interval, in milliseconds, to send DWR (DeviceWatchdogRequest)
; Interval allowed: 10000..600000
; Defaults to 60000
;dwr_interval=60000

; dwr_timeout: integer: Timeout, in milliseconds, of a DWR (DeviceWatchdogRequest)
; When a DWR times out the connection will be closed
; Interval allowed: 1000..60000
; Defaults to 3000
;dwr_timeout=3000

; conn_start_timeout: integer: Interval, in milliseconds, for connection start
; Incoming: Wait to to receive CapabilitiesExchangeRequest
; Outgoing: Wait to to receive CapabilitiesExchangeAnswer
; If CER/CEA is not received within this interval the connection willl be closed
; Interval allowed: 10000..180000
; Defaults to 60000
;conn_start_timeout=60000

; bind_interval: integer: Interval, in milliseconds, to try listener re-bind on failure
; It can be overridden in listener sections
; Allowed interval: 10000..300000
; Defaults to 60000
;bind_interval=60000

; bind_reuse: boolean: Set socket reuse when binding an outgoing connection
; This parameter is applied on reload when a connect attempt is made
; This parameter can be overridden when creating a new connection (user.login)
; Defaults to no
;bind_reuse=no

; transaction_ttl: integer: Incoming transaction time to live, in milliseconds
;  This is the interval to track (keep) an incoming transaction (request)
; Used to detect retransmissions and send the same response
; NOTES:
; - This parameter is applied on reload
; - Transitions from non 0 to 0 are ignored. I.e. incoming transactions tracking
;   can't be disabled after enable
; - Setting a long expire value may affect performance: transactions list will grow
; Allowed interval: 0..300000
; If not 0 it will be forced to be at least 10000
; Defaults to 0
;transaction_ttl=0

; redirect_max: integer: Maximum allowed number of redirect indication allowed for a request
; This parameter can be overridden when a node is updated
; Interval allowed: 0..10
; Defaults to 0: redirect not handled
;redirect_max=0

; loops_alarm_thres: integer: Threshold for detected loops alarm
; This parameter configures the interval (number of detection) to put an alarm when a
;  loop is detected by a node
;loops_alarm_thres=100

; trans_mutexpool_length: integer: Length of transaction mutex pool
; This pool is used to assign a mutex to a transaction
; This parameter is applied when transaction tracking is enabled
; Use a prime number to make sure transaction mutexes are properly distributed
; Minimum allowed value is 101
; Defaults to 307
;trans_mutexpool_length=307

; trans_in_hash_length: integer: Number of hash lists used to distribute tracked transactions
; This parameter is applied when transaction tracking is enabled
; Use a prime number to make sure transactions are properly distributed
; Minimum allowed value is 13
; Defaults to 29
;trans_in_hash_length=29

; backlog: integer: Maximum length of the queue of listener pending connections
; It can be overridden in listener sections
; Set it to 0 for system maximum
; Defaults to 5
;backlog=5

; buflen: integer: Socket read buffer length
; Minimum allowed value: 256
; Defaults to 4096
;buflen=4096

; request_send_first_node_origin: boolean: Send a non proxied command request:
;  use the first found (or created) node as origin (host/realm, session id, end-to-end identifier)
;  even if failed to send the request using it
; If disabled subsequent nodes will override command's origin data
; This parameter may be overridden when sending a request
; Defaults to yes
;request_send_first_node_origin=yes

; request_send_create_node: boolean: Send a non proxied command request:
;  create a local node if required node is not found and use it to
;  set command's origin host/realm, session id and end-to-end identifier
; This parameter may be overridden when sending a request
; This parameter is ignored if 'request_send_first_node_origin' is disabled
; Defaults to yes
;request_send_create_node=yes

; export_xml_as: string: Specify in which way the XML will be passed along into
;  Yate messages
; Allowed values are:
;  - string: pass the XML as a string
;  - object: pass the XML as an object
;  - both: pass the XML as a string and object
; Defaults to object
;export_xml_as=object

; sctpparam_: string: Socket parameter to set to SCTP sockets
; This parameter is applied on reload for new connections only
; E.g. sctpparam_rto_initial would set SCTP initial retransmission
; See lksctp.conf.sample for parameters list

; vendor_id: integer: Product vendor id to advertise
; This parameter can be overridden when creating a new node (in user.login or user.register)
; Defaults to 34501 (Null Team)
;vendor_id=34501

; product_name: string: Product name to advertise
; This parameter can be overridden when creating a new node (in user.login or user.register)
;product_name=YATE/${version}

; firmware_revision: string/integer: Firmware revision to advertise
; This parameter can be overridden when creating a new node (in user.login or user.register)
;firmware_revision=${revision}

;printmsg=yes
; printmsg: keyword/boolean: Print sent/received messages to output/log
; Defaults to yes
; Set it to 'verbose' to print XML elements' children, attributes or text on
;  separate lines
; Set it to 'short' to print message root XML tag and attributes only
;printmsg=yes

; printmsg_peers: boolean: Print connection peers (local/remote node) when printing
;  sent/received messages
; Defaults to no
;printmsg_peers=no

; track_msg_level: integer: Debug level to track messages
; Used to debug send message operations
; This parameter can be overridden from handled message
; Set it to 0 to disable
; Defaults to 0
;track_msg_level=0

; track_msg_extended: boolean: Put extended debug info when tracking a message
; This parameter can be overridden from handled message
; Defaults to no
;track_msg_extended=no


;[listener name]
; Configures a listener whose name is 'name'
; The following parameters can be overridden from 'general' section:
;  bind_interval, backlog
; Listener parameters are applied on reload only if idle or invalid (incorrect
;   previous configuration)
; If the listener is binding or listening parameters are not applied
; All parameters from 'general' section starting with 'sctpparam_' can also be overridden
;  for connections received on this listener
; All parameters from starting with 'conn_' are applied on reload and will be passed to
;  incoming connections received by this listener

; enable: boolean: Enable or disable this listener
; Defaults to yes
;enable=yes

; type: string: Listener type
; Allowed values: sctp, tcp, tls
; Defaults to sctp
; This parameter is not applied on reload
;type=sctp

; addr: string: Address to bind to
; If empty the listener will try first to listen on all IPv4 addresses
; If IPv4 fails it will try to listen on all IPv6 addresses
;addr=

; port: integer: Port to bind
; Defaults to 3868 for sctp/tcp and 5658 for tls
;port=

; sctp_bindx: string: Extra address to bind a SCTP listener
; This parameter may be repeated to bind a SCTP listener on more addresses
; If the bind address is IPv4 non IPv4 addresses specified in sctp_bindx will be ignored
; If the bind address is IPv6:
;   ipv6only=yes: non IPv6 addresses specified in sctp_bindx will be ignored
;   ipv6only=no: sctp_bindx may specify IPv4 and IPv6 addresses
; This parameter is ignored for non SCTP listeners
;sctp_bindx=

; bind_reuse: boolean: Set socket reuse when binding
; This parameter is applied on reload when a bind retry is made
; Defaults to yes
;bind_reuse=yes

; ipv6only: boolean: Use only IPv6 addresses
; If enabled the listener will accept only IPv6 connections
; This parameter is ignored if not listening on an IPv6 address
; Defaults to yes
;ipv6only=yes

; sslcontext: string: SSL context if this is an encrypted connection
; Ignored for non TLS listeners, required for TLS listeners
;sslcontext=


[handlers]
; This section configures diameter message handlers
; Handler priorities are not applied on reload

; priority: integer: Message handlers priority
;priority=100

References

  • RFC 3588 - Diameter Base Protocol
  • RFC 4006 - Diameter Credit-Control Application
  • RFC 6733 - Diameter Base Protocol
  • RFC 6737 - Diameter Capabilities Update Application
  • RFC 6408 - Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage
  • RFC 5516 - Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)
  • ETSI TS 129.272 - MME and SGSN related interfaces based on Diameter protocol (S6a/S6d, S7a/S7d, S13/S13')
Personal tools
Namespaces

Variants
Actions
Preface
Configuration
Administrators
Developers