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
Hello. We use 2 kamailio servers cluster and we have porblems with db. Database failed pecause of error:
Could not execute Write_rows_v1 event on table production.location; Duplicate entry 'uloc-54aae947-86d-a67' for key 'ruid_idx', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log FIRST, end_log_pos 380, Internal MariaDB error code: 1062
But a location table no row 'ruid_idx' and no entry uloc-54aae947-86d-a67.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/30
Hi Daniel,
I must admit this run_onsend() patch for stateful replies creation was
not quite a success story. However, I think it serves a practical
purpose, for example in Homer tracing and could be useful for the
community. Again, I propose my past solution, with some questions:
1. I am unsure if the place I introduced the run_onsend call is
appropriate since the buf used for msg_send is constructed
build_res_buf_from_sip_req and build_res_buf_from_sip_res calls.
2. Also, we can maybe unite these if call branches I created:
send_res = msg_send(&uas_rb->dst, buf, res_len);
send_res = SEND_PR_BUFFER( uas_rb, buf, res_len );
3. Do you think a get_send_socket snippet as follows should be inserted
before the /*if (onsend_route_enabled(SIP_REPLY)){*/ :
if(dst.send_sock == NULL) {
dst.send_sock=get_send_socket(msg, &dst.to, dst.proto);
if (dst.send_sock==0){
LM_ERR("cannot forward reply\n");
}
}
Thank you,
Lucian
On 10/29/2014 02:15 PM, Daniel-Constantin Mierla wrote:
> Hello Lucian,
>
> I applied your patch with some fixes.
>
> I haven't checked with stateful replies, at some point a function from
> core should be used. You can go ahead and see if it works, if not, let
> me know and I can look into it as well. You can follow the callbacks
> for TMCB_RESPONSE_OUT or TMCB_RESPONSE_FWDED inside tm code, they
> should lead to the place where a sip response is going to be sent out.
>
> Cheers,
> Daniel
>
> On 27/10/14 12:51, Lucian Balaceanu wrote:
>> Hello Daniel,
>>
>> I must admit I only saw your mail last Friday. Until the 10th of
>> October I was also on vacation. I know that you actually committed
>> some of the changes together with your comments on the 12th this month.
>>
>> I don't know if we can consider the topic of the patch closed. As far
>> as I understand, the state-full replies have not been addressed,
>> right? (There should be a change in the t_reply.c) I followed the
>> code to the relay_reply but I did not yet come to find the send
>> function. Should I pursue further?
>>
>> Thank you,
>> Lucian Balaceanu
>>
>>> Hi Lucian,
>>>
>>> somehow I forgot to follow up on this. But we need to get sorted out
>>> soon, before we release, so it works as expected with the new
>>> version. See more comments inline.
>>>
>>>
>>> On 17/09/14 18:09, Lucian Balaceanu wrote:
>>>> Hi Daniel,
>>>>
>>>> Please forgive me for my delay in responding to your mail.
>>>> Please find attached a second version of the onsend_route_reply
>>>> patch (which again has some problems). As per your previous
>>>> indications I did the following:
>>>>
>>>> *Issue1*
>>>>> From performances point of view, there can be added a config
>>>>> parameter to enable running of onsend_route for replies:
>>>>>
>>>>> onsend_route_reply = 0|1
>>>>
>>>> Following
>>>> http://www.asipto.com/pub/kamailio-devel-guide/#c08add_parameters I
>>>> have tried to add onsend_route_reply parameter. The code compiles,
>>>> but when trying to start kamailio with this parameter inside, the
>>>> parsing fails with syntax errors signaling:
>>>>
>>>> / 0(1321) :<core> [cfg.y:3423]: yyerror_at(): parse error in config
>>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108,
>>>> column 0: syntax error
>>>> 0(1321) : <core> [cfg.y:3423]: yyerror_at(): parse error in config
>>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108,
>>>> column 0:
>>>> ERROR: bad config file (2 errors)/
>>>
>>> The issue is:
>>>
>>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext);
>>> + yy_number_str=yytext; return NUMBER; }
>>>
>>> It should be:
>>>
>>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext);
>>> + yy_number_str=yytext; return ONSEND_RT_REPLY; }
>>>
>>>>
>>>> *Issue2*
>>>>> #define onsend_enabled(rtype)
>>>>> (onsend_rt.rlist[DEFAULT_RT]?((rtype==SIP_REPLY)?onsend_route_reply:1):0)
>>>> That is to say you see it best to take the chek for
>>>> onsend_rt.list[DEFAULT_RT] from inside run_onsend() function and
>>>> call this onsend_enabled(...) before the run_onsend()?
>>>
>>> This is to detect whether the onsend_route should be executed for
>>> SIP replies. The condition being:
>>>
>>> - if is a sip reply and onsend_route is set and the
>>> onsend_route_reply parameter is 1
>>>>
>>>> *Issue3*
>>>>> On the other hand, is onsend_route also executed for local
>>>>> requests? I had in mind it is only for received requests that are
>>>>> forwarded ... Iirc, on onsend_route, the sip message is the one
>>>>> received, the outgoing content being accessible via $snd(buf).
>>>>>
>>>> I agree with you with taking out the locally generated requests and
>>>> only left the run_onsend call in do_forward_reply function (inside
>>>> forward.c).
>>>> Could you point me to the reply relaying function that is called
>>>> for state-full processing?
>>> Stateful processing for replies is mainly done in t_reply.c from tm
>>> module. At some point there should be a send buffer function call.
>>>
>>> Cheers,
>>> Daniel
>>>>
>>>> Thank you and sorry again for my late answer,
>>>> Lucian
>>>
>>> --
>>> Daniel-Constantin Mierla
>>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>>>
>>>
>>
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda