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/09/07 10:21] – [Kamailio Config File] 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 ===== | ===== Overview ===== | ||
Line 9: | Line 9: | ||
The [[http:// | The [[http:// | ||
+ | {{ : | ||
===== SIP Routing ===== | ===== SIP Routing ===== | ||
Line 22: | Line 23: | ||
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. | 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 ===== | ===== Presentations ===== | ||
Line 885: | 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 1017: | Line 1080: | ||
</ | </ | ||
+ | ===== Resources ===== | ||
+ | |||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[https:// |