Router
Documentation based on repostory git version commit 2.4.0-alpha-156-ge33acd59
Module Router
The Router module routes requests for domains it manages.
The routing algorithm is as follows:
- first skip route headers that directly point to this proxy.
- if a route header is found that doesn't point to this proxy, then the request is not processed by the Router module, and will be handled by the Forward module at the end of the processing chain.
- examine the request-uri: if it is part of the domains managed by this proxy (according to Registrar module 'reg-domains' definition, then attempt to resolve the request-uri from the Registrar database.
- the results from the registrar database, in the form of contact headers, are sorted by priority (q parameter), if any.
- for each set of contact with equal priorities, the request is forked, and sent to their corresponding sip URI. After a timeout defined by property 'call-fork-current-branches-timeout', a next set of contact header is determined.
- responses are received from all attempted branches, and sent back to the request originator, according to the procedure of RFC3261 16.7 Response processing.
The router module offers different variations of the routing logic, depending on whether it is an INVITE, a MESSAGE, or another type of request. The processing of MESSAGE request essentially differs from others because it allows to keep the MESSAGE for a later delivery, in which case the incoming transaction will be terminated with a 202 Accepted response.
----
Configuration options:
Name | Description | Default Value | Default Unit | Type |
---|---|---|---|---|
enabled | Indicate whether the module is activated. | true | Boolean | |
filter | A request/response enters module if the boolean filter evaluates to true. Ex: from.uri.domain contains 'sip.linphone.org', from.uri.domain in 'a.org b.org c.org', (to.uri.domain in 'a.org b.org c.org') && (user-agent == 'Linphone v2'). You can consult the full filter documentation here : https://wiki.linphone.org/xwiki/wiki/public/view/Flexisip/Configuration/Filter%20syntax/ | BooleanExpr | ||
use-global-domain | Store and retrieve contacts without using the domain. | false | Boolean | |
fork-late | Fork invites to late registers. | false | Boolean | |
fork-no-global-decline | All the forked have to decline in order to decline the caller invite. | false | Boolean | |
treat-decline-as-urgent | Treat 603 Declined answers as urgent. Only relevant if fork-no-global-decline is set to true. | false | Boolean | |
treat-all-as-urgent | During a fork procedure, treat all failure response as urgent. | false | Boolean | |
call-fork-timeout | Maximum time for a call fork to try to reach a callee. | 90 | second | DurationS |
call-fork-urgent-timeout | Maximum time before delivering urgent responses during a call fork. The typical fork process requires to wait the best response from all branches before transmitting it to the client. However some error responses are retryable immediately (like 415 unsupported media, 401, 407) thus it is painful for the client to need to wait the end of the transaction time (32 seconds) for these error codes. | 5 | second | DurationS |
call-fork-current-branches-timeout | Maximum time before trying the next set of lower priority contacts. | 10 | second | DurationS |
message-fork-late | Fork MESSAGE requests to client registering lately. | true | Boolean | |
message-delivery-timeout | Maximum duration for delivering a MESSAGE request. This property applies only if message-fork-late is 'true'; otherwise, the duration can't exceed the normal transaction duration. | 604800 | second | DurationS |
message-accept-timeout | Maximum duration for accepting a MESSAGE request if no response is received from any recipients. This property is meaningful when message-fork-late is set to true. | 5 | second | DurationS |
message-database-enabled | If 'true', the message that are waiting for delivery will be stored in database instead of memory. | false | Boolean | |
message-database-backend | Choose the type of backend that Soci will use for the connection. Depending on your Soci package and the modules you installed, the supported databases are:`mysql` (and `sqlite3` soon) | mysql | String | |
message-database-connection-string | The configuration parameters of the backend. The basic format is "key=value key2=value2". For a mysql backend, this is a valid config: "db=mydb user=user password='pass' host=myhost.com". Please refer to the Soci documentation of your backend, for instance: http://soci.sourceforge.net/doc/master/backends/#supported-backends-and-features | db='mydb' user='myuser' password='mypass' host='myhost.com' | String | |
message-database-pool-size | Size of the pool of connections that Soci will use for accessing the message database. | 100 | Integer | |
fallback-route | Default route to apply when the recipient is unreachable or when when all attempted destination have failed.It is given as a SIP URI, for example: sip:example.org;transport=tcp (without surrounding brackets) | String | ||
allow-target-factorization | During a call forking, allow several INVITEs going to the same next hop to be grouped into a single one. A proprietary custom header 'X-target-uris' is added to the INVITE to indicate the final targets of the INVITE. | false | Boolean | |
permit-self-generated-provisional-response | Whether the proxy is allowed to generate and send provisional responses during a call forking process. A typical example for this is the '110 Push sent' emitted by the proxy when at least one push notification has been sent to a target UA while routing an INVITE. Some old versions of Linphone (below linphone-sdk 4.2) suffer from an issue when receiving such kind of provisional responses that don't come from a remote client. This setting is mainly intended to temporarily workaround this situation. | true | Boolean | |
resolve-routes | Whether or not to resolve next hop in route header against registrar database. This is an extension to RFC3261, and should not be used unless in some specific deployment cases. A next hope in route header is otherwise resolved through standard DNS procedure by the Forward module. | false | Boolean | |
parent-domain-fallback | Whether or not to fallback to the parent domain if there is no fallback route set and the recipient is unreachable. For example, if routing to sip:bob@a.b.com returns no result, route the request to b.com. This is also a non-standard behavior. | false | Boolean | |
fallback-route-filter | Only use the fallback route if the expression is true. | true | BooleanExpr | |
max-request-retention-time | Max time the proxy will retain a request in order to maintain order. | 30 | second | DurationS |
static-targets | List of sip addresses that are always added to the list of contacts fetched from the registrar database when routing INVITE and MESSAGE requests. | StringList |