THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#100 - Assignment operators don't work
User who did this - Alex Hermann (axlh)
http://sip-router.org/tracker/index.php?do=details&task_id=100
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
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 …
[View More]
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.
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/8
[View Less]
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 …
[View More]GitHub:
https://github.com/kamailio/kamailio/issues/30
[View Less]
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 …
[View More]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
[View Less]