SIPMSGOPS module

Admin Guide

Overview

The module implements SIP based operations over the messages processed by OpenSIPS. SIP is a text based protocol and the module provides a large set of very useful functions to manipulate the message at SIP level, e.g., inserting new headers or deleting them, check for method type, etc.

Dependencies

OpenSIPS Modules

The following modules must be loaded before this module:

No dependencies on other OpenSIPS modules.

External Libraries or Applications

The following libraries or applications must be installed before running OpenSIPS with this module loaded:

None.

Exported Functions

append_to_reply(txt)

Append ‘txt’ as header to all replies that will be generated by OpenSIPS for this request.

Meaning of the parameters is as follows:

txt (string) - SIP header field, value and CRLF marker.

This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE, ERROR_ROUTE.

...
append_to_reply("Foo: bar\r\n");
append_to_reply("Foo: $rm at $Ts\r\n");
...

append_hf(txt[, hdr_anchor])

Appends ‘txt’ as header after the last header field. If ‘hdr_anchor’ is given, ‘txt’ will be appended after the first occurrence of ‘hdr_anchor’ instead.

Meaning of the parameters is as follows:

txt (string) - Header field to be appended.
hdr_anchor (string, optional) - Header name after which the ‘txt’ is appended.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.

...
append_hf("P-hint: VOICEMAIL\r\n");
append_hf("From-username: $fU\r\n");
append_hf("From-username: $fU\r\n", "Call-ID");
...

insert_hf(txt)

Inserts ‘txt’ as header before the first header field.

Meaning of the parameters is as follows:

txt (string) - Header field to be inserted.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.

...
insert_hf("P-hint: VOICEMAIL\r\n");
insert_hf("To-username: $tU\r\n");
...

insert_hf(txt, hdr)

Inserts ‘txt’ as header before first ‘hdr’ header field.

Meaning of the parameters is as follows:

txt (string) - Header field to be inserted.
hdr (string, optional) - Header name before which the ‘txt’ is inserted.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.

...
insert_hf("P-hint: VOICEMAIL\r\n", "Call-ID");
insert_hf("To-username: $tU\r\n", "Call-ID");
...

append_urihf(prefix, suffix)

Append header field name with original Request-URI in middle.

Meaning of the parameters is as follows:

prefix - string (usually at least header field name).
suffix - string (usually at least line terminator).

This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.

...
append_urihf("CC-Diversion: ", "\r\n");
...

is_present_hf(hf_name)

Return true if a header field is present in message.

Meaning of the parameters is as follows:

hf_name (string) - Header field name (long or compact form).

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.

...
if (is_present_hf("From")) log(1, "From HF Present");
...

append_time()

Adds a time header to the reply of the request. You must use it before functions that are likely to send a reply, e.g., save() from ‘registrar’ module. Header format is: “Date: %a, %d %b %Y %H:%M:%S GMT”, with the legend:

%a abbreviated week of day name (locale)
%d day of month as decimal number
%b abbreviated month name (locale)
%Y year with century
%H hour
%M minutes
%S seconds

Return true if a header was successfully appended.

This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE.

...
append_time();
...

is_method(name)

Check if the method of the message matches the name. If name is a known method (invite, cancel, ack, bye, options, info, update, register, message, subscribe, notify, refer, prack), the function performs method ID testing (integer comparison) instead of ignore case string comparison.

The ‘name’ can be a list of methods in the form of ‘method1|method2|…’. In this case, the function returns true if the SIP message’s method is one from the list. IMPORTANT NOTE: in the list must be only methods defined in OpenSIPS with ID (invite, cancel, ack, bye, options, info, update, register, message, subscribe, notify, refer, prack, publish; for more see: https://www.iana.org/assignments/sip-parameters).

If used for replies, the function tests the value of method field from CSeq header.

Meaning of the parameters is as follows:

name (string) - SIP method name

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, and BRANCH_ROUTE.

...
if(is_method("INVITE"))
{
    # process INVITEs here
}
if(is_method("OPTION|UPDATE"))
{
    # process OPTIONs and UPDATEs here
}
...

remove_hf(hname)

Remove from message all headers with name “hname”

Returns true if at least one header is found and removed.

Meaning of the parameters is as follows:

hname (string) - header name to be removed.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE and BRANCH_ROUTE.

...
if(remove_hf("User-Agent"))
{
    # User Agent header removed
}
...

remove_hf_re(hname_expr)

Remove from message all headers matching the “hname_expr” POSIX regular expression.

Returns true if at least one header is found and removed.

Meaning of the parameters is as follows:

hname_expr (string) - regular expression.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE and BRANCH_ROUTE.

...
remove_hf_re("^X-g.+[0-9]");
...

remove_hf_glob(hname_pattern)

Remove from message all headers matching the “hname_pattern” glob pattern.

Returns true if at least one header is found and removed.

Meaning of the parameters is as follows:

hname_pattern (string) - glob pattern

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE and BRANCH_ROUTE.

...
# removes X-Billing-Account, X-Billing-Price, X-Billing-rateplan, etc
remove_hf_glob("X-Billing*");
...

has_totag()

Check if To header field uri contains tag parameter.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
if (has_totag()) {
  ...
};
...

ruri_has_param(param[,value])

Find if Request URI has a given parameter. If no value is given, the function will look for the paramter with no value, oherwise it will search for the parameter with the matching value.

Meaning of the parameters is as follows:

param (string) - parameter name to look for.
value (string, optional) - parameter value to match.

This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
if (ruri_has_param("user","phone")) {
  ...
};
...

ruri_add_param(param)

Add to RURI an URI parameter formated as “name=value”.

Meaning of the parameters is as follows:

param (string) - parameter to be appended in “name=value” format.

This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
ruri_add_param("nat=yes");
...

ruri_del_param(param)

Delete a parameter from the RURI being given the key(key=value);

Meaning of the parameters is as follows:

param (string) - key of the parameter to be removed/

This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
ruri_del_param("user");
...

ruri_tel2sip()

Converts RURI, if it is tel URI, to SIP URI. Returns true, only if conversion succeeded or if no conversion was needed (like RURI was not tel URI.

This function can be used from REQUEST_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
ruri_tel2sip();
...

is_uri_user_e164(uri)

Checks if the username part of the given URI is an E164 number.

Meaning of the parameters is as follows:

uri (string) - a SIP URI

This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.

...
if (is_uri_user_e164($fu)) {  # Check From header URI user part
   ...
}
if (is_uri_user_e164($avp(uri)) {
   # Check user part of URI stored in avp uri
   ...
};
...

has_body_part([mime])

The function returns true if the SIP message has any body part with the given MIME. If there is no MIME given, it will return true if at least one body part is found (with any MIME).

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE and BRANCH_ROUTE.

...
if(has_body_part("application/sdp"))
{
    # do interesting stuff here
}
...

is_audio_on_hold()

The function returns true if the SIP message has an SDP body attached and at least one audio stream in on hold. The return code of the function indicates the detected hold type:

1 - RFC2543 hold type: null connection IP detected
2 - RFC3264 hold type: inactive or sendonly attributes detected

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE and BRANCH_ROUTE.

...
if(is_audio_on_hold())
{
    switch ($rc) {
    case 1:
        # RFC2543 hold type
      # do interesting stuff here
        break;
    case 2:
        # RFC3264 hold type
      # do interesting stuff here
        break;
}
...

is_privacy(privacy_type)

The function returns true if the SIP message has a Privacy header field that includes the given privacy_type among its privacy values. See https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-8 for possible privacy type values.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE and BRANCH_ROUTE.

...
if(is_privacy("id"))
{
    # do interesting stuff here
}
...

remove_body_part([mime[, revert]])

Removes from the message body all the body parts with the given mime. The necessary corrections over the Content-Type and Content-Length headers are automatically done.

If a MIME type is given, it will delete only the body parts with that mime. If no MIME given, all the parts (entire body) will be removed.

Meaning of the parameters is as follows:

mime (string, optional) - MIME type to be checked against the body parts; If not given, all parts are to remvoed;
revert (string, optional) - useful only if a MIME was specified. If “revert” string is given here, the function will delete all body parts but the ones with the given MIME.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
# delete entire body message (all parts)
remove_body_part();
# delete all body parts with mime "application/isup"
remove_body_part("application/isup");
# delete all body parts but keep the the ones with  "application/sdp"
remove_body_part("application/sdp","revert")
...

add_body_part(body, mime[, headers])

This function can be used to add a new body part to the message body. If another part already exist, body of the message will be converted to a multi-part body automatically.

Meaning of the parameters is as follows:

body (string) - the content of the body part to be added
mime (string) - the mime string for the body part to be added
headers (string, optional) - optional list of SIP headers (fully defined, including the header separator) to be pushed into this part next to the Content-Type header.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
add_body_part("Hello World!", "text/plain");
...

sipmsg_validate([flags[, result_pvar]])

The function returns true if the SIP message is properly built according to SIP RFC3261. It verifies if the mandatory headers for each request/reply and can also check the format of the headers body.

The flags parameter received is optional and can be composed with the following values:

‘s’ - checks the integrity of the SDP body, if it exists
‘h’ - checks the format and integrity of each header body.
‘m’ - don’t check the Max-Forwards header.
‘r’ - checks the R-URI and whether the domain contains valid characters.
‘f’ - checks the URI of the ‘From’ field and whether the domain contains valid characters.
‘t’ - checks the URI of the ‘To’ field and whether the domain contains valid characters.
‘c’ - checks the URI of the ‘Contact’ field.

The result_pvar parameter sets resulting pvar with text error reason in case of negative result ( easy for logging or propagating the rejection reason back to the bogus UA )

This function can return the following codes:

1 - the message is RFC3261 compliant and has been successfully validated.
-1 - No SIP message
-2 - Header Parsing error
-3 - No Call-ID header
-4 - No Content-Length header for transports that require it ( eg. TCP )
-5 - Invalid Content-Length, other from the size of the actual body
-6 - SDP body parsing error.
-7 - No Cseq header.
-8 - No From header.
-9 - No To header.
-10 - No Via header.
-11 - Request URI parse error.
-12 - Bad hostname in R-URI.
-13 - No Max-Forwards header.
-14 - No Contact header.
-15 - Path user for non-Register request.
-16 - No allow header in 405 reply.
-17 - No Min-Expire header in 423 reply.
-18 - No Proxy-Authorize header in 407 reply.
-19 - No Unsupported header in 420 reply.
-20 - No WWW-Authorize header in 401 reply.
-21 - No Content-Type header
-22 - To header parse error
-23 - Bad hostname in To header
-24 - From header parse error
-25 - Bad hostname in From header
-26 - Contact header parse error
-255 - undefined errors.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE and BRANCH_ROUTE.

...
if(!sipmsg_validate())
{
  send_reply(400, "Bad Request");
  exit;
}
...

...
# checks also the SDP and headers body
if(!sipmsg_validate("sh", $var(err_reason)))
{
  send_reply(400, "Bad Request/Body");
  exit;
}
...

codec_exists (name[, clock])

This function can be used to verify if a codec exists inside an sdp payload. It will search for the codec inside all streams from all sdp sessions. If it is found anywhere it will return TRUE otherwise it will return FALSE.

Parameters:

name (string) - Parameter is CASE INSENSITIVE.
clock (string, optional) - if not supplied any clockrate will match. Parameter is CASE INSENSITIVE.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
codec_exists("speex");
or
codec_exists("GSM", "8000");
...

codec_delete(name[, clock])

This function can be used to delete a codec from inside an sdp payload. It will search for the codec inside all streams from all sdp sessions. If it is found anywhere it will be deleted from the mapping (“a=…”) and from the list of indexes (“m=…”). Returns TRUE if any deletion occurred otherwise it will return FALSE.

name (string) - Parameter is CASE INSENSITIVE.
clock (string, optional) - if not supplied any clockrate will match and all will be deleted. Parameter is CASE INSENSITIVE.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
codec_delete("speex");
or
codec_delete("GSM", "8000");
...

codec_move_up(name[, clock])

This function can be used to move a codec up in the list of indexes (“m=…”). It will search for the codec inside all streams from all sdp sessions. If it is found anywhere it will be moved to the top of the index list. Returns TRUE if any moves occurred otherwise it will return FALSE.

name (string) - parameter is CASE INSENSITIVE.
clock (string, optional) - if not supplied any clockrate will match and all codecs will be moved to the front while preserving their original ordering. Parameter is CASE INSENSITIVE.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
codec_move_up("speex");
or
codec_move_up("GSM", "8000");
...

codec_move_down(name[, clock])

This function can be used to move a codec down in the list of indexes (“m=…”). It will search for the codec inside all streams from all sdp sessions. If it is found anywhere it will be moved to the back of the index list. Returns TRUE if any moves occurred otherwise it will return FALSE. The second parameter is optional, if it is not supplied any clockrate will match and all codecs will be moved to the back while preserving their original ordering. Parameters are CASE INSENSITIVE.

name (string) - parameter is CASE INSENSITIVE.
clock (string, optional) - if not supplied any clockrate will match and all codecs will be moved to the back while preserving their original ordering. Parameter is CASE INSENSITIVE.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
codec_move_down("speex");
or
codec_move_down("GSM", "8000");
...

...
/*
  This example will move speex with 8000 codec to the back of the list,
  then it will erase GSM with 8000 clock, and then it will bring all
  speex codecs to the front of the list. Speex/8000 will be behind any
  other speex.
*/
codec_move_down("speex", "8000");
codec_delete("GSM", "8000");
codec_move_up("speex");
...

codec_exists_re ( regexp )

This function has the same effect as codec_exists ( without the clock parameter ) the only difference is that it takes a POSIX regular expression as a parameter.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
codec_exists_re("sp[a-z]*");
...

codec_delete_re ( regexp )

This function has the same effect as codec_delete ( without the clock parameter ) the only difference is that it takes a POSIX regular expression as a parameter.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
codec_delete_re("PCMA|PCMU");
...

codec_delete_except_re ( regexp )

This function deletes all the codecs except those specified by the regular expression.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
codec_delete_except_re("PCMA|PCMU");#will delete all codecs except PCMA and PCMU
...

codec_move_up_re ( regexp )

This function has the same effect as codec_move_up ( without the clock parameter ) the only difference is that it takes a POSIX regular expression as a parameter.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
codec_move_up_re("sp[a-z]*");
...

codec_move_down_re ( regexp )

This function has the same effect as codec_move_down ( without the clock parameter ) the only difference is that it takes a POSIX regular expression as a parameter.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
codec_move_down_re("sp[a-z]*");
...

...
/*
  This example will move speex with 8000 codec to the back of the list,
  then it will erase GSM with 8000 clock, and then it will bring all
  speex codecs to the front of the list. Speex/8000 will be behind any
  other speex.
*/
codec_move_down("speex","8000");
codec_delete("GSM","8000");
codec_move_up("speex");
...

change_reply_status(code, reason)

Intercept a SIP reply (in any onreply_route) and change its status code and reason phrase prior to propogating it.

Meaning of the parameters is as follows:

code (int) - Status code.
reason (string) - Reason phrase.

This function can be used from ONREPLY_ROUTE.

...
onreply_route {
    if ($rs == "603") {
        change_reply_status(404, "Not Found");
        exit;
    }
}
...

stream_exists(regexp)

This function can be used to verify if a stream exists inside an sdp payload. It will search for the stream inside all sdp sessions. If it is found anywhere it will return TRUE otherwise it will return FALSE.

Meaning of the parameters is as follows:

regexp - a POSIX regular expression to match the stream media name.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
# check for FAX
stream_exists("image");
...

stream_delete(regexp)

This function can be used to delete a whole stream from inside an sdp payload. It will search for the stream inside all sdp sessions. If it is found anywhere it will be deleted along with all attributes Returns TRUE if any deletion occurred otherwise it will return FALSE.

Meaning of the parameters is as follows:

regexp - a POSIX regular expression to match the stream media name.

This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
# prevent usage of video
stream_delete("video");
...

list_hdr_has_option(hdr_name, option)

Checks and returns true if the given option/token is listed in the body of the given header. The header must have its body formated as a CSV list of tokens/option (like the Supported, Require, Content-Dispsition headers) body format

Meaning of the parameters is as follows:

hdr_name (string) - the name of the header to be checked. Note that all instances of that header will be checked (if the header has multiple instances in the SIP message). Any kind of header name is supported - RFC3261 standard, RFC extensions or custom names.
opt (string) - the option/tolen to be searched for.

The function returns true if the options was found listed in one of the header instances. If no header was found, if the option was not found or if there was a parsing or runtime error, false will be returned. This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
# check if 100rel is advertised
if (list_hdr_has_option("Supported", "100rel"))
  xlog("100rel option found\n");
...

list_hdr_add_option(hdr_name, option)

Add a new option/token at the end of the list in the body of the given header. The header must have its body formated as a CSV list of tokens/option (like the Supported, Require, Content-Disposition headers) body format

Multiple add / remove operations can be performed over the same header.

Meaning of the parameters is as follows:

hdr_name (string) - the name of the header where the option has to be added. If multiple instances of that header are present in the SIP message, the add will be performed on the first instance. Any kind of header name is supported - RFC3261 standard, RFC extensions or custom names.
opt (string) - the option/token to be added to the CSV list. Note there is not verification for duplicated (if the newly added option is not already present in the header).

The function returns true if the options was successfully added to the listed of the given header. If no header was found or if there was a parsing or runtime error, false will be returned. This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
# add 100rel for advertising
if (!list_hdr_has_option("Supported", "100rel"))
    list_hdr_add_option("Supported", "100rel");

list_hdr_remove_option(hdr_name, option)

Removes an option/token from the list inside the body of the given header. The header must have its body formated as a CSV list of tokens/option (like the Supported, Require, Content-Dispsition headers) body format

Multiple add / remove operations can be performed over the same header.

Meaning of the parameters is as follows:

hdr_name (string) - the name of the header where the option has to be removed from. If the option is duplicated in the same header, only the last one will be removed. If multiple instances of that header are present in the SIP message, the remove will be performed on all instance instance. Any kind of header name is supported - RFC3261 standard, RFC extensions or custom names.
opt (string) - the option/token to be removed from the CSV list. Note that if this the only option in the header, the whole header will be removed.

The function returns true if the options was successfully removed from at least one heaer instance. If no header was found or if the token was not found or if there was a parsing or runtime error, false will be returned. This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE, FAILURE_ROUTE, BRANCH_ROUTE and LOCAL_ROUTE.

...
# add 100rel for advertising
if (list_hdr_has_option("Supported", "100rel"))
    list_hdr_remove_option("Supported", "100rel");
list_hdr_add_option("Supported", "optionX");

Known Limitations

Search functions are applied to the current message so modifications made to the sdp will be visible to the codec_exists functions( e.g. after calling codec_delete(“speex”) , codec_exists(“speex”) will return false ).

Contributors

By Commit Statistics

Top contributors by DevScore⁽¹⁾, authored commits⁽²⁾ and lines added/removed⁽³⁾

#	Name	DevScore	Commits	Lines++	Lines—
1.	Bogdan-Andrei Iancu (@bogdan-iancu)	61	29	2290	712
2.	Liviu Chircu (@liviuchircu)	54	21	943	1499
3.	Razvan Crainea (@razvancrainea)	52	18	3822	47
4.	Stefan Darius (@dariusstefan)	22	4	1478	249
5.	Mihai Tiganus (@tallicamike)	21	3	737	610
6.	Vlad Paiu (@vladpaiu)	9	4	314	101
7.	Vlad Patrascu (@rvlad-patrascu)	4	2	49	13
8.	Ovidiu Sas (@ovidiusas)	4	2	23	2
9.	Peter Lemenkov (@lemenkov)	4	2	2	2
10.	Boris Ratner	4	1	132	49

All remaining contributors: Nick Altmann (@nikbyte), Julián Moreno Patiño, Fabian Gast (@fgast), Alexey Vasilyev (@vasilevalex), Jarrod Baumann (@jarrodb), Ezequiel Lovelle (@lovelle), Walter Doekes (@wdoekes), Ionut Ionita (@ionutrazvanionita), Dan Pascu (@danpascu).

(1) DevScore = author_commits + author_lines_added / (project_lines_added / project_commits) + author_lines_deleted / (project_lines_deleted / project_commits)

(2) including any documentation-related commits, excluding merge commits

(3) ignoring whitespace edits, renamed files and auto-generated files

By Commit Activity

#	Name	Commit Activity
1.	Stefan Darius (@dariusstefan)	Jun 2026 - Jul 2026
2.	Razvan Crainea (@razvancrainea)	Feb 2012 - Jun 2026
3.	Liviu Chircu (@liviuchircu)	Nov 2012 - Sep 2020
4.	Bogdan-Andrei Iancu (@bogdan-iancu)	Feb 2012 - Nov 2019
5.	Dan Pascu (@danpascu)	May 2019 - May 2019
6.	Vlad Patrascu (@rvlad-patrascu)	May 2017 - Apr 2019
7.	Alexey Vasilyev (@vasilevalex)	Jan 2019 - Jan 2019
8.	Fabian Gast (@fgast)	Nov 2018 - Nov 2018
9.	Peter Lemenkov (@lemenkov)	Jan 2013 - Jun 2018
10.	Ovidiu Sas (@ovidiusas)	Feb 2018 - Feb 2018

All remaining contributors: Jarrod Baumann (@jarrodb), Julián Moreno Patiño, Ionut Ionita (@ionutrazvanionita), Ezequiel Lovelle (@lovelle), Vlad Paiu (@vladpaiu), Mihai Tiganus (@tallicamike), Boris Ratner, Nick Altmann (@nikbyte), Walter Doekes (@wdoekes).

(1) including any documentation-related commits, excluding merge commits

Documentation

Contributors

Last edited by: Razvan Crainea (@razvancrainea), Liviu Chircu (@liviuchircu), Vlad Patrascu (@rvlad-patrascu), Fabian Gast (@fgast), Bogdan-Andrei Iancu (@bogdan-iancu), Peter Lemenkov (@lemenkov), Ovidiu Sas (@ovidiusas), Julián Moreno Patiño, Mihai Tiganus (@tallicamike), Vlad Paiu (@vladpaiu), Boris Ratner, Nick Altmann (@nikbyte).

License

All documentation files (i.e. .md extension) are licensed under the Creative Common License 4.0