It seems a good idea to support JWT as a new SIP authorization method. Wonder if anyone is interested? Think auth_db would be the best spot to add support for JWT.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/29
We have avp_copy on avpops module but we don’t have anything to copy xavps.
```
// copy all the content of an avp to a xavp
$xavp(a[0]=>b) = $(avp(x)[*]);
// deleting left content
$xavp(a[0]=>b[*]) = $(avp(x)[*]);
// copy xavp to a xavp with index
$xavp(a[0]) = $xavp(b[1]);
// all
$xavp(a[*]) = $xavp(b[*]);
// copy all content of a xavp to a avp
$avp(x) = $xavp(a[0]=>b[*]);
```
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/7
Hello,
As you will see I have merged my branch back into master.
These changes add a new event route [tm:branch-failure] to the tm module
which is run when any failure response is received on a transaction.
The event_route uses a new route type BRANCH_ROUTE which limits the
functions that can be run in the route.
The functions t_check_status(), t_next_contact_flow(), t_relay() and
unregister() can be used in this route.
A new pv $T_reply_ruid is accessible in this route which can be used to
unregister a single contact entry.
The following example route can be used on a registrar to handle failed
or invalid flows:
event_route[tm:branch-failure] {
xlog("L_INFO", "event_route[tm:branch-failure]\n");
if (t_check_status("430|403")) {
if (!unregister("location", "$tu", "$T_reply_ruid"))
{
xlog("L_WARN", "failed to unregister $tu with
ruid $T_reply_ruid\n");
}
if (!t_next_contact_flow())
{
xlog("L_INFO", "No more flows\n");
}
else
{
xlog("L_INFO", "Next flow\n");
t_relay();
}
}
}
Any bugs, memory leaks etc. let me know!
Hugh
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
If a PUBLISH request is sent before a 200 OK for the previous PUBLISH request is received, the E-Tag is reset which leads to inconsistent presentity data in the presence server.
This is happening because the second PUBLISH is sent with the same E-Tag as the previous one, but the presence server has an updated the E-Tag (generated while handling the first PUBLISH).
The pua module should implement a queuing mechanism for subsequent PUBLISH request while a previous PUBLISH transaction is in progress. No new PUBLISH requests should be sent before a response to the previous PUBLISH request was received and the E-Tag updated.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/21
In testing environment It would be nice to be able to append sip headers `X-Kamailio-test` and `X-Kamailio-test-ID` as a way to identify a collection of request/responses related to a a single test.
Be able to generate tests reports via debugger RPC command using the value of `X-Kamailio-test` as key.
The content of report could be:
* SIP message received
* SIP messages sended
* flow of config execution routes ( `start`, `end`, `exit` )
* list of the variable and its value
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/8