Router
Documentation based on repostory git version commit 2.0.2-5-g0c973c23
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 | 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') | 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, in seconds. | 90 | Integer |
| call-fork-urgent-timeout | Maximum time before delivering urgent responses during a call fork, in seconds. 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 | Integer |
| call-fork-current-branches-timeout | Maximum time in seconds before trying the next set of lower priority contacts. | 10 | Integer |
| call-push-response-timeout | Optional timer to detect lack of push response, in seconds. | 0 | Integer |
| 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 if set to true, otherwise the duration can't exceed the normal transaction duration. | 604800 | Integer |
| 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 | 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 brakets) | 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 |