sr-dev December 2014

sr-dev@lists.kamailio.org

33 participants
255 discussions

[kamailio] avpops: avp_copy add xavp (#7)

by Victor Seva

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

5 years, 1 month

git:master:b450a769: Updated P-CSCF example with additional Rx_AAR params

by Richard Good

Module: kamailio Branch: master Commit: b450a769cff3b5c8ea0962299f6b087da089cd59 URL: https://github.com/kamailio/kamailio/commit/b450a769cff3b5c8ea0962299f6b087… Author: Richard Good <richard.good(a)smilecoms.com> Committer: Richard Good <richard.good(a)smilecoms.com> Date: 2014-12-17T10:58:00+02:00 Updated P-CSCF example with additional Rx_AAR params --- Modified: examples/pcscf/kamailio.cfg --- Diff: https://github.com/kamailio/kamailio/commit/b450a769cff3b5c8ea0962299f6b087… Patch: https://github.com/kamailio/kamailio/commit/b450a769cff3b5c8ea0962299f6b087… --- diff --git a/examples/pcscf/kamailio.cfg b/examples/pcscf/kamailio.cfg index c09cdc9..c2d5f55 100644 --- a/examples/pcscf/kamailio.cfg +++ b/examples/pcscf/kamailio.cfg @@ -983,7 +983,7 @@ route[Orig_Initial] #!ifdef WITH_RX xlog("L_DBG","Diameter: Orig authorizing media via Rx\n"); - if(Rx_AAR("ORIG_SESSION_AAR","orig")==0){ + if(Rx_AAR("ORIG_SESSION_AAR","orig","",-1)==0){ exit; } } @@ -1035,7 +1035,7 @@ onreply_route[Orig_Initial_reply] #!ifdef WITH_RX if (t_check_status("180|183|200")){ xlog("L_DBG","Diameter: Orig authorizing media via Rx\n"); - if(Rx_AAR("ORIG_SESSION_AAR_REPLY","orig")==0){ + if(Rx_AAR("ORIG_SESSION_AAR_REPLY","orig","",-1)==0){ exit; } } @@ -1089,7 +1089,7 @@ route[Term_Initial] #!ifdef WITH_RX xlog("L_DBG","Diameter: Term authorizing media via Rx\n"); - if(Rx_AAR("TERM_SESSION_AAR","term")==0){ + if(Rx_AAR("TERM_SESSION_AAR","term","",-1)==0){ exit; } } @@ -1138,7 +1138,7 @@ onreply_route[Term_Initial_reply] #!ifdef WITH_RX if (t_check_status("180|183|200")){ xlog("L_DBG","Diameter: Orig authorizing media via Rx\n"); - if(Rx_AAR("TERM_SESSION_AAR_REPLY","term")==0){ + if(Rx_AAR("TERM_SESSION_AAR_REPLY","term","",-1)==0){ exit; } }

6 years, 9 months

Outbound flow failure handling merged to master

by Hugh Waite

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.

7 years, 12 months

[kamailio] debugger: config test report (#8)

by Victor Seva

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

8 years, 10 months

Re: [sr-dev] Is there a sense in calling run_onsend() after the msg_send() function?

by Lucian Balaceanu

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

9 years, 2 months

TM possible deadlock

by Jason Penton

Hi All, I have been experiencing a deadlock when a timeout occurs on a t_relayed() INVITE. Going through the code I have noticed a possible chance of deadlock (without re-entrant enabled). Here is my thinking: t_should_relay_response() is called with REPLY_LOCK when the timer process fires on the fr_inv_timer (no response from the INVITE that was relayed, other than 100 provisional) and a 408 is generated. However, from within that function there are calls to run_failure_handlers() which in turn *could* try and lock the reply (viz. somebody having a t_reply() call in the cfg file - in failure route block). This would result in another lock on the same transaction's REPLY_LOCK.... Has anybody else experienced something like this? this is on master btw. Cheers Jason

9 years, 7 months

Refreshing the Kamailio logo

by Daniel-Constantin Mierla

Hello, I was considering to discuss the state of Kamailio project logo for a while. The current state is ambiguous, to say at least - various logos in different places. When OpenSER was renamed in Kamailio we were trying to get something new, but due to the 'forks and dark waters' at that time, this process was never completing, meanwhile using an adaptation of old openser logo. However, there are no high resolution or other variants suitable for using in particular conditions (e.g., black and white, big posters). First, a question that we should decide on: shall we aim for a new logo or try to get someone to make proper graphics from the current shape? (for reference, the logo from http://www.kamailio.org/wp-images/kamailio-rock-logo.jpg). I would prefer to go for a new logo, but I admit that this process can become complex, a mater of tastes, not something we can decide on technical aspects. Therefore, if it ends up in something that doesn't seem to have the acceptance of major contributors (with coding, advertising/promoting, ...) to the project, then we stick with current for a while. My preference is based on the fact that Kamailio evolved over the time, has its own identity, so a fresh look of the logo would reflect that better. I am listing here the options, that people can express preference on: A) New logo A1) variant based on Kamailio World logo (used by twitter kamailioproject account and on some materials at various events). It was a backup variant so far as we had high resolution graphics that could be adapted to get a good image for big posters. Can be seen at: - http://www.kamailio.org/pub/kamailio-logos/variants/kamailio-from-world-log… - http://www.fredposner.com/1471/kamailio-at-astricon-2013/ A2) use a professional service for that. Kamailio World logo was made with 99designs.com service, which is quite good considering there will be many submissions to choose between, options can be visible by everyone. There might be other similar services, this is one I have experience with and worked fine in the past -- anyhow, it has to be something that all management and solution can be done online. Asipto can sponsor at least the bronze package if 99designs is going to be used, maybe others want to participate with extra funds to get a better package. A3) leverage on community, in case some companies have internal designers or some of you have such skills or friends. Perhaps this has the highest risk on escalating, given that is going to be some direct involvement in proposals and selection. B) Old logo B1) get someone to produce high resolution graphics from existing logo No matter what variant, who will do the work or financial contribution, will get credits via our web site. However, all the rights of the resulting logo will belong to the Kamailio project. To conclude, the order of my preferences: A2, A1, A3, B1 Looking forward to feedback from many of you! Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

9 years, 9 months

[kamailio] "core parsing of SIP message failed" with tcp defragmented message (#9)

by ultraboby

Contact: <sip:xxxxxxxxxxxx@x.x.x.x:5060;alias=x.x.x.x~48094~2>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service> 4(21951) ERROR: <core> [receive.c:149]: receive_msg(): core parsing of SIP message failed (x.x.x.x:5060/1) 4(21951) ERROR: <core> [parser/msg_parser.c:277]: get_hdr_field(): ERROR: get_hdr_field: bad body for <Contact: <sip:x.x.x.x@x.x.x.x:5060;alias=x.x.x.x~48094~2>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service>(7) 4(21951) INFO: <core> [parser/msg_parser.c:355]: parse_headers(): ERROR: bad header field [Contact: <sip:xxxxx] 4(21951) ERROR: <core> [parser/msg_parser.c:705]: parse_msg(): ERROR: parse_msg: message=<INVITE sip:xxxxxxxxxxxx@x.x.x.x:5060;alias=x.x.x.x~5060~1 SIP/2.0 --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/9

9 years, 9 months

For developers: update of your write access to git repository (now on github)

by Daniel-Constantin Mierla

Hello, a message with explicit subject in order to make it easier to be spotted, to be sure every active developer is becoming aware of the change. The GIT repository for Kamailio project is now hosted to Github: - https://github.com/kamailio/kamailio To be able to push commits directly to it, send me your Github user id. If you already did it, then just ignore this message. Your local clone taken from git.sip-router.org needs to get an update to remote URL - inside the folder do: git remote set-url origin https://github.com/kamailio/kamailio.git You can use ssh with Github, if you prefer it: git remote set-url origin ssh+git://git@github.com/kamailio/kamailio.git For more details on access, see: - https://help.github.com/articles/which-remote-url-should-i-use/ Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

9 years, 10 months

[kamailio] Improve for correct working with all RADIUS AV pairs (#14)

by borikinternet

In this pull request I`d correct work with retrieved from RADIUS AV pairs for modules auth_radius, misc_radius and peering. Now this modules correctly put to $avp() all retrieved params: - integer name and integer value - integer name and string value - string name and integer value - string name and string value All above said and for SIP-AVP params too. You can merge this Pull Request by running: git pull https://github.com/borikinternet/kamailio master Or you can view, comment on it, or merge it online at: https://github.com/kamailio/kamailio/pull/14 -- Commit Summary -- * Improve for correct working with all RADIUS AV pairs -- File Changes -- M modules/auth_radius/sterman.c (180) M modules/misc_radius/functions.c (228) M modules/peering/verify.c (205) -- Patch Links -- https://github.com/kamailio/kamailio/pull/14.patch https://github.com/kamailio/kamailio/pull/14.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/14

9 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev December 2014