kamailio:k43-async-sip-routing-nodejs
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| kamailio:k43-async-sip-routing-nodejs [2015/07/28 09:33] – admin | kamailio:k43-async-sip-routing-nodejs [2015/09/07 11:36] (current) – [Async SIP Routing with Kamailio and Node.js] admin | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Async SIP Routing with Kamailio and Node.js ====== | ====== Async SIP Routing with Kamailio and Node.js ====== | ||
| - | **Work in progress | + | Node.js-based external routing decision engine for Kamailio. |
| + | |||
| + | ===== Overview ===== | ||
| The aim is to show how to leverage [[http:// | The aim is to show how to leverage [[http:// | ||
| Line 7: | Line 9: | ||
| The [[http:// | The [[http:// | ||
| + | {{ : | ||
| + | ===== SIP Routing ===== | ||
| + | |||
| + | The routing JSON document format specified by the [[http:// | ||
| + | |||
| + | Serial and parallel forking are the basic mechanisms for forwarding SIP traffic: | ||
| + | |||
| + | * serial forking - try several destinations one after the other, waiting for a final response on each try, stopping when one answered with 200ok or there is no other destination to try | ||
| + | * parallel forking - try several destinations at once, stopping when one answered with 200ok and cancelling the other active branches, or when all branches responded with a negative response. | ||
| + | |||
| + | Leveraging the two routing mechanisms, one can implement various routing engine such as load balancer, least cost routing, group hunting, call forwarding (on no answer, busy, etc.). Kamailio has dedicated modules (e.g., dispatcher, lcr, ...) to provide those features, but sometimes the logic behind deciding what is the best route to follow might not match existing components. Writing an application in nodejs might be faster or better integrated in the overall environment (e.g., when dealing with multiple nodes), than writing a new module in C. Obviously, the code written in C is always expected to run faster. | ||
| + | |||
| + | The tutorial here is aiming to offer a basic example, which should help building more complex external applications for deciding the SIP routing to be performed by Kamailio. | ||
| + | |||
| + | ==== RTJSON Routing Document ==== | ||
| + | |||
| + | The structure for RTJSON routing document is detailed at: | ||
| + | |||
| + | * [[http:// | ||
| + | |||
| + | Next is a partial example, with the attributes for one destination: | ||
| + | |||
| + | <code javascript> | ||
| + | { | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | [ | ||
| + | { | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | }, | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | }, | ||
| + | " | ||
| + | }, | ||
| + | " | ||
| + | " | ||
| + | " | ||
| + | }, | ||
| + | ... | ||
| + | ] | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | The **routing** field specify if Kamailio has to do serial or parallel forking. After that, the relevant routing information is an array of destinations stored in **routes** field. | ||
| + | |||
| + | Each destination corresponds to a SIP branch that is going to be created by Kamailio. For each branch can be specified values to set: | ||
| + | |||
| + | * request uri | ||
| + | * outbound proxy address (dst uri) | ||
| + | * display name and uri for From/To headers | ||
| + | * extra headers | ||
| + | * retransmission and ringing timeouts | ||
| + | * local socket or the path to be followed | ||
| + | * branch flags | ||
| + | |||
| + | The example above results in: the request will be routed to sip: | ||
| + | |||
| + | ==== EVAPI Processing ==== | ||
| + | |||
| + | EVAPI is sort of generic framework to push events to external application from inside kamailio.cfg via TCP connections. It has the capability of suspending the processing of the SIP request until there is a response from the external application. By suspending the SIP request, other SIP messages can be processes, thus not blocking Kamailio while waiting for event response. This asynchronous mechanism enables high throughput for SIP routing. | ||
| + | ===== Presentations ===== | ||
| + | |||
| + | The presentation at Cluecon 2015 by Daniel-Constantin Mierla includes content about this tutorial: | ||
| + | |||
| + | * [[http:// | ||
| + | * [[http:// | ||
| ===== Kamailio Config File ===== | ===== Kamailio Config File ===== | ||
| Line 23: | Line 101: | ||
| * add the routing blocks specific for evapi module | * add the routing blocks specific for evapi module | ||
| * use jansson to investigate returned JSON document and take decision of what to do | * use jansson to investigate returned JSON document and take decision of what to do | ||
| + | |||
| + | ==== Config Diff ==== | ||
| The diff of the config file comparing with the default one: | The diff of the config file comparing with the default one: | ||
| Line 143: | Line 223: | ||
| </ | </ | ||
| + | |||
| + | ==== Full Config ==== | ||
| The full config file is: | The full config file is: | ||
| Line 860: | Line 942: | ||
| * http:// | * http:// | ||
| - | A simple sample application is shown next: | + | A simple sample application is shown next example. It connects to Kamailio' |
| - | < | + | To read more about nestring format, see: |
| + | |||
| + | * https:// | ||
| + | |||
| + | Node.js application: | ||
| + | |||
| + | < | ||
| var net = require(' | var net = require(' | ||
| Line 992: | Line 1080: | ||
| </ | </ | ||
| + | ===== Resources ===== | ||
| + | |||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[http:// | ||
| + | * [[https:// | ||