In route block I call t_on_failure, t_on_branch_failure, and
t_on_branch. If branch route fails like this:
Dec 15 08:52:19 box /usr/bin/sip-proxy[84346]: ERROR: tm [ut.h:284]:
uri2dst2(): failed to resolve "foo.tutpro.com" :unresolvable A or request
(-7)
Dec 15 08:52:19 box
I noticed this in t_newtrans() README:
Note that any flag operations (e.g. for accounting) after this
function has been called will be ignored. You can use the the tmx
module function t_flush_flags() to flush the altered flags to the
already created transaction.
The text is wrong. I
Thanks for the tip. 0 + $null is int. The bug is that $null should be nothing,
not an empty string.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
e type of PVs, as they
>originated from xlog, where the output was a string to be printed.
>
>"" + 0 should be "0"
>
>Cheers,
>Daniel
>
>On 01.12.19 02:35, Juha Heinanen wrote:
>> Why is it that $null + 0 is 0 but not int? What is it?
>>
>
Why is it that $null + 0 is 0 but not int? What is it?
-- Juha
$avp(test) = $null + 0;
if (is_int("$avp(test)"))
INFO(test $avp(test) IS int);
else
INFO(test $avp(test) IS NOT int);
Dec 1 02:46:01 salmon /usr/bin/sip-proxy[10138]: INFO: test 0 IS NOT int
Daniel-Constantin Mierla writes:
> Yes, you can add it there.
Done. Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
> Yes, MOD_xxx is defined automatically when module xxx is loaded.
Good. Would core cookbook define section be a place to document this?
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
I have used in config file these kind of constructs:
#!ifdef MOD_
...
#!endif
Is the MOD_xxx keyword automatically set when module xxx is loaded?
Perhaps I have invented the whole concept in a dream?
-- Juha
___
Kamailio (SER) - Users Mailing List
amit Kumar writes:
> As per our requirement, when A party send a cancel to B party we do not
> want "200 cancelling" message from Kamailio.We try to find any high-level
> flag to disable it. but could not able to find. Can you please help us on
> how to achieve this.
Try to forward the request
Yuriy Gorlichenko writes:
> Not sure if it availible for 4.x Version but for 5.x There is a tcp
> connection closed event route
> https://kamailio.org/docs/modules/4.4.x/modules/tcpops.html#tcpops.f.tcp_enable_closed_event
> You can try to play around it to get ip that distorbs you.
My
Daniel-Constantin Mierla writes:
> Probably the IP address can be printed in that log message from the C
> code, at that level the tcp connection structure (associated with the
> tls session) should be filled in with source ip and destination ip.
> Obviously it requires to patch the code -- I can
Yuriy Gorlichenko writes:
> Looks no, because connection must be established for handling it in the
> config file. This error fired by ssl library during Negotiation process.
>
> But you can try tcpdump, at least you will see Who tries to established
> connection
Yes, I could do that, but I
Sometimes I see in syslog errors like this:
Oct 15 16:44:57 salmon /usr/bin/sip-proxy[2064]: ERROR: tls [tls_util.h:42]:
tls_err_ret(): TLS accept:error:1417C086:SSL
routines:tls_process_client_certificate:certificate verify failed
Is it possible somehow to catch the error in config file, for
Kamailio wiki does not tell what result $sht(htable=>key) gives if the
key is not found in htable. It would be nice if it did.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
Daniel-Constantin Mierla writes:
> The mysql client library is stuck, waiting for a poll event to happen.
> It is the insert done for accounting on SIP response.
>
> It is hard to say what is the reason, maybe you can install the debug
> symbols for lib mysql client library and the the backtrace
Juha Heinanen writes:
> Here is two traps taken about 8 minutes apart during the same freeze:
>
> https://box.tutpro.com/tmp/gdb_kamailio_20190902_120249
> https://box.tutpro.com/tmp/gdb_kamailio_20190902_121032
>
> During the freeze, it was possible to make MySQL queries to
b...@novatrope.us writes:
> Installed Kam 5.2.4, but now getting version mismatch on evapi.
>
> ERROR: [core/sr_module.c:348]: version_control(): module version
> mismatch for /usr/lib64/kamailio/modules/evapi.so; core: kamailio 5.2.4
> (x86_64/linux); module: kamailio 5.1.6 (x86_64/linux)
>
Daniel-Constantin Mierla writes:
> If you have access to the system when that blocks in this way during
> that interval, take the output of 'kamctl trap' or the backtrace with
> gdb for a sip udp worker process.
Got trap of all processes. Placed it here:
Daniel-Constantin Mierla writes:
> That's why backtrace would help to see where the processes are stuck.
Thanks for your comments. Backtrace will be taken during next freeze.
-- Juha
___
Kamailio (SER) - Users Mailing List
Daniel-Constantin Mierla writes:
> What is the version? Practically kamctl trap is wrapping around gdb
> batch commands to get the backtrace of all kamailio processes.
I found it.
-- Juha
___
Kamailio (SER) - Users Mailing List
Daniel-Constantin Mierla writes:
> Being reply processing, one potential operation that can be slow is
> writing the acc record to the database. Any external tool blocking the
> acc tables?
I'm not sure about that. Unfortunately there was no SIP over TCP calls
during the UDP freeze so that
Daniel-Constantin Mierla writes:
> If you have access to the system when that blocks in this way during
> that interval, take the output of 'kamctl trap' or the backtrace with
> gdb for a sip udp worker process.
Didn't find 'kamctl trap', will try gdb.
-- Juha
Daniel-Constantin Mierla writes:
> Can you see what is the next debug message printed by pid 19674?
Below is a few lines of the process before the freeze and a few after
(freeze took this time about 13 minutes). Looks like the process
resumed processing of the same sip request.
> If you have
During the UDP freeze, ss shows:
udp UNCONN 429312 0 x.x.x.x:5060 *:*
tcp LISTEN 0 128 x.x.x.x:5060 *:*
i.e., there is lots of bytes in UDP receive queue, which K has not
picked up.
I don't see anything special in debug log when the udp freeze started at
about
Joel Serrano writes:
> Did you check to see if UDP packets (maybe?) are being queued at the
> network level before reaching K?
Thanks for the tip. Will check next time ($ ss -4 -n -l | grep 5060).
-- Juha
___
Kamailio (SER) - Users Mailing List
Juha Heinanen writes:
> Any ideas what could cause Kamailio (5.2 version) to stop processing
> requests over UDP? What additional info should I try to get?
Is there some means to find out if a UDP receiver process is currently
processing a request?
Forgot to mention that after about 10 m
I'm returning to an old issue, where Kamailio stops processing incoming
requests.
Now it turned out that only requests over UDP are not processed.
Requests over TCP work fine. Debug log doesn't show anything about the
requests over UDP, but wireshark sees them coming. core.ps shows that
main
Answering to my own question: use the same set order both in offer and
answer.
-- Juha
> When set_rtpengine_set() is called with two parameters before
> rtpengine_offer(), e.g.
>
> set_rtpengine_set("1", "2");
> rtpengine_offer();
>
> it was not clear to me from rtpengine README, if the sets
Daniel-Constantin Mierla writes:
> I just pushed the commit adding the {s.count,c} parameter:
Thanks, Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
My sip proxy has two rtpengine sets:
# sip-proxy_ctl rtpengine.show all
{
url: udp:192.26.134.1:6050
set: 0
index: 0
weight: 1
disabled: 0
recheck_ticks: 0
}
{
url: udp:192.26.134.40:6050
set: 1
index: 1
weight: 1
One alternative could be to implement
{s.count, delimiter}
which would tell how many items a list separated by delimiter has.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
Daniel-Constantin Mierla writes:
> iirc, the comma does not work as delimiter between parameters, because
> it is the delimiter between the header bodies (when many bodies are
> serialized within same header name).
I thought that comma can be used as param.count delimiter, because it
works as
Looks like there is bug in {param.count,delimiter} transformation:
$var(test) = "a=1;b=2";
xinfo("param count = $(var(test){param.count,;})\n");
$var(test) = "a=1,b=2";
xinfo("param count = $(var(test){param.count,,})\n");
syslog:
Aug 19 11:27:27 salmon
When set_rtpengine_set() is called with two parameters before
rtpengine_offer(), e.g.
set_rtpengine_set("1", "2");
rtpengine_offer();
it was not clear to me from rtpengine README, if the sets need to
reversed when set_rtpengine_set() is called before rtpengine_answer(),
i.e.,
Daniel-Constantin Mierla writes:
> If I haven't missed something, Juha said it is not good to ask the user
> again for introducing the password in the (soft)phone app. The hashed
> response (with nonce, realm, password) has to be sent always over the
> network, no matter the stale parameter
Daniel-Constantin Mierla writes:
> With the above considerations, to make it specs compliant, the code has to
> be extended that even in the case of expired nonce, the auth_db (and the
> other auth* variants) has to go further to compute the response and if
> there was a match, then add
Juha Heinanen writes:
> > Moreover, the latest recommendations in security is to disclose as less as
> > possible what was not "correct", avoiding responses like "invalid user id"
> > or "invalid password".
>
> I agree with that, but in c
Daniel-Constantin Mierla writes:
> I am not sure if this option is actually implemented according to the
> specs. iirc, stale=true should be set when the server checks the username
> and password and all is ok, but the nonce is expired. afaik, the check for
> nonce expiration is done before
Henning Westerholt writes:
> sounds like a good idea to me, we should integrate it to the default cfg.
>
> Just a small comment, I think this would be match the current behaviour
> more closely (only return stale=true, don't use qop=auth).
>
> ! case -4:
> !
Several people are complaining on baresip git that Kamailio is among
those SIP servers that don't handle stale nonce properly, i.e., don't
include stale=true flag in WWW-Authenticate header of 401 response.
I have tried to tell that Kamailio does what it has been configured to
do, but the
Carsten Bock writes:
> However, this does not seem to apply to the transcoding options. When I
> just call "rtpengine_manage()" for a Re-INVITE of a transcoded call (in my
> case AMR-WB to G722), the transcoding options are no longer applied. The
> forwarded offer does not get the transcoded
Daniel-Constantin Mierla writes:
> Any preference for one of the two options?
I would prefer release after holidays. Freeze and testing OK during
that period.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
Sergiu Pojoga writes:
>
> Noticed BYE requests relayed from caller to callee have the
> *Proxy-Authorization* header including *Digest*, *nonce* and *response*.
>
> Is that by SIP definition or am I doing something wrong? My concern is the
> callee gets to see caller's authentication
I tried to use sdp_remove_codecs_by_id("101") to remove "codec" 101
(dtmf) from sdp, but nothing happened. It is still there:
m=audio 31128 UDP/TLS/RTP/SAVPF 101 96.
c=IN IP4 192.168.43.88
a=label:1.
a=rtcp-rsize.
a=ssrc:2880178656 cname:sip:t...@test.tutpro.com.
a=rtpmap:101
Daniel-Constantin Mierla writes:
> Speaking of that, can someone test with both:
>
> auto_bind_ipv6=1
>
> bind_ipv6_link_local=1
>
> And see if kamailio listen on all available IPv6 addresses, including
> the link local ones?
You mean start K without any listen directives?
I tried and it
Sergey Safarov writes:
> listen=proto:[linklocalip%nic]:port advertise ...
I like the above more than a new iface token. linklocalip%nic is
already in use by other apps (apache, telnet, etc.).
-- Juha
___
Kamailio (SER) - Users Mailing List
Sergey Safarov writes:
> That because to bind link local address need to define used NIC like
>
> sipp -sn uas -i fe80::b951:ef1f:76c8:e5a2%eth0
Yes, this kind of syntax worked:
$ sipp fe80::6e29:95ff:fe7d:37e6%wlp1s0 -p 5050 -m 1 -sf register.sipp -t t1 -i
fe80::6e29:95ff:fe7d:37e6%wlp1s0 -p
Daniel-Constantin Mierla writes:
> can you try with latest master and set the next global parameter?
>
> bind_ipv6_link_local=1
>
> Along with the usual listen on a link local ipv6 address.
>
> Let me know if it works.
It worked at least with UDP. I was not able to test with TCP or TLS.
I
R, Rajkumar (Raj) writes:
> I think elaborating on the setup may help someone to provide inputs on
> this. Below is the setup.
> Client 1 --> Kamailio proxy --> Backend SIP server
> Client 2 --> Kamailio proxy --> Backend SIP server
> Client 3 --> Kamailio proxy --> Backend SIP server
>
>
Daniel-Constantin Mierla writes:
> OK, thanks for testing and feedback! Have you also tried for tcp/tls?
Yes, with this kind of code in tcp_main.c:
} else if(sock_info->address.af==AF_INET6){
if (setsockopt(sock_info->socket, IPPROTO_IPV6, IPV6_TCLASS,
Daniel-Constantin Mierla writes:
> I pushed a patch to compare ips using parsed structure. Initial version
> was using string comparison, which is not safe for ipv6, but I was
> looking for a quick proof of a solution.
>
> The role of this ip comparison is to figure out what is the interface
>
Juha Heinanen writes:
> It would be better to use the name of the interface (in above wlp1s0)
> with call if_nametoindex(ifname). Is the name available?
In baresip ifname is available and I can use the if_nametoindex() call.
I don't know where it got the name,
-
Daniel-Constantin Mierla writes:
> Can you try without hard coding the IP address there, but use the value
> from the listen address? That will show if works properly with the
> config based values.
I tried like this:
addr->sin6.sin6_scope_id =
Daniel-Constantin Mierla writes:
> Can you try without hard coding the IP address there, but use the value
> from the listen address? That will show if works properly with the
> config based values.
I used constant address, since I was not able to easily figure out,
where the address string is
Daniel-Constantin Mierla writes:
> Anyhow, your code has hardcoded interface name, I added a helper
> function that tries to get the scope by matching the ip address when
> walking over network interfaces. The commit:
>
>
I read K source code and found these kind of lines in sock_info.c:
for(;RTA_OK(rtap, rtl);rtap=RTA_NEXT(rtap,rtl)){
switch(rtap->rta_type){
case IFA_ADDRESS:
David Villasmil writes:
> You didn’t set a protocol, like:
>
> listen=udp:[2a02:1850:1:1::13]:5060
From the wiki:
listen
Set the network addresses the SIP server should listen to. It can be an
IP address, hostname or network iterface id or combination of
protocol:address:port (e.g.,
Joel Serrano writes:
> How are you setting the listen= param for ipv6?
I have tried with these three:
listen=[fe80::6e29:95ff:fe7d:37e6]:5060
listen=[fe80::6e29:95ff:fe7d:37e6%wlp1s0]:5060
listen=fe80::6e29:95ff:fe7d:37e6%wlp1s0:5060
The last one works in apache. K does not accept the syntax
This thread discusses the same problem with apache web server:
https://serverfault.com/questions/751170/apache-linux-httpd-listen-on-link-local-ipv6-address
The conclusion was that this kind of syntax works:
/etc/httpd/conf/httpd.conf:Listen fe80::a00:16ff:fe89:420f%3:80
that is, ipv6 address
Juha Heinanen writes:
> Did I do something wrong? If not, why is it that K cannot listen at a
> link local address? It is something that Linux networking stack does
> not support?
I did more tests and found out that I can even ssh to the link local
address:
$ ssh fe80::6e29:95ff:
My K host is behind a mobile WiFi hotspot and I tried to make K listen at
the IPv6 address fe80::6e29:95ff:fe7d:37e6/64 that the host has received
from the hotspot.
Using that address on listen line gives error:
Apr 21 08:55:18 salmon /usr/bin/sip-proxy[6887]: ERROR:
[core/udp_server.c:395]:
Henning Westerholt writes:
> > I did some tests with auth_ephemeral. When timestamp has expired, I get
> > to syslog
> >
> > Feb 23 03:53:05 char /usr/bin/sip-proxy[31758]: WARNING: auth_ephemeral
> > [authorize.c:205]: autheph_verify_timestamp(): username has expired Feb 23
> > 03:53:05 char
Juha Heinanen writes:
> It was Debian Stretch installed on (if I remember correctly) xen virtual
> machine. I'll check to be sure.
Yes, it was VM on XenServer.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
Daniel-Constantin Mierla writes:
> Can you tell what linux distro and version was running in your case?
> Also, can you give the output for:
It was Debian Stretch installed on (if I remember correctly) xen virtual
machine. I'll check to be sure.
-- Juha
I did some tests with auth_ephemeral. When timestamp has expired, I get
to syslog
Feb 23 03:53:05 char /usr/bin/sip-proxy[31758]: WARNING: auth_ephemeral
[authorize.c:205]: autheph_verify_timestamp(): username has expired
Feb 23 03:53:05 char /usr/bin/sip-proxy[31758]: ERROR: auth_ephemeral
Daniel-Constantin Mierla writes:
> However, that had invalid access to transaction pointer. In this case,
> accessing transaction is ok, by setting a variable to the address of one
> of its fields, but then the variable becomes NULL, which is not possible
> unless the stack got
Daniel-Constantin Mierla writes:
> replying to the initial message to have the backtrace easy to look at
> its content...
>
> The info locals in frame 0 show:
>
> uac = 0x0
>
> However, that is set few lines above as:
>
> uac=>uac[branch];
>
> An address of a variable (or field in a
Daniel-Constantin Mierla writes:
> OK. It happens to be traveling for few days, once I am back, I will dig
> into it and see how to fix this long delayed processing so it does not
> crash.
Thanks for looking into this. Perhaps the freeze is due to some locking
issue like the one when K didn't
I got the full syslog and pcap and based on those K indeed totally froze
for about 14 minutes. Below is updated summary:
- K receives INVITE at 17:43:28 and forwards it over udp to uas
- uas immediately responds with 183 followed by 180, which k forwards to UAC
- at 17:44:29 uas responds again
Daniel-Constantin Mierla writes:
> OK. There should be no crash no matter what caused the delay. I wanted
> to sort out the freezing of entire kamailio for 15min, because that is
> rather unusual to happen for all processes and then recover.
>
> I will look more at the tm for this delay/blocking
Juha Heinanen writes:
> Thanks. I don't think that this is db related issue. Here is a
> summary:
>
> - K receives INVITE at 17:43:28 and forwards it over udp to uas
> - uas immediately responds with 183 followed by 180, which k forwards to UAC
> - at 17:44:29 uas responds ag
Daniel-Constantin Mierla writes:
> It is rather strange that it got like "frozen" for 15 minutes. Was there
> a high CPU during that interval?
CPU was not high and that top showed nothing unusual during the freeze.
Also, there was nothing special in MySQL logs.
> Typically, if there is a
Daniel-Constantin Mierla writes:
> I'll look into it. Was there a possibility that some operation could
> have taken very long, for example writing accounting database record?
Thanks. I don't think that this is db related issue. Here is a
summary:
- K receives INVITE at 17:43:28 and forwards
Juha Heinanen writes:
> pcap shows that kamailio receives from the uas two "180 ringing" replies
> 30 secs apart after which fr_inv_timeout hits. at that point kamailio
> sends "408 request timeout" to uac and gets back ack. then 45 secs
> later, kamailio gets o
Juha Heinanen writes:
> Kamailio 5.2 crashed when it received 480 reply to INVITE. Below is
> backtrace from the core file.
>
> The crash happens in t_reply.c on the last line of this block:
>
> uac=>uac[branch];
Kamailio 5.2 crashed when it received 480 reply to INVITE. Below is
backtrace from the core file.
The crash happens in t_reply.c on the last line of this block:
uac=>uac[branch];
LM_DBG("org. status uas=%d, uac[%d]=%d local=%d
Daniel-Constantin Mierla writes:
> I just pushed a series of commits trying to rework how loading (and
> reloading) of rtpegines list is done, to avoid that sync'ed probing,
> which can take long if any of the rtpengines is down.
Daniel,
Thanks for the commit. Now K starts responding
Daniel-Constantin Mierla writes:
> You can make a fix yourself if you want and have the time. It is not a
> module I coded, nor the one that added db support for it, so I am also
> coding by learning what was done there.
Understand. Perhaps the solution for now is to disable db mode in the
Daniel-Constantin Mierla writes:
> I pushed a quick fix for the case when db support is not enabled,
> because these locks are useless in that case, so all children will do
> the rtpengine init at the same time, without waiting for the others:
Still took in rtpengine db mode about 2 minutes
Daniel-Constantin Mierla writes:
> Maybe you would also want to tune the timeout with the modparam:
>
> modparam("rtpengine", "rtpengine_disable_tout", 5)
>
> So detection of unavailable rtpproxy is fast, otherwise it is 60 sec by
> default, so you may still experience some slow start per child
Daniel-Constantin Mierla writes:
> I was able to figure out what could be the cause with:
>
> modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223
> udp:192.168.64.4:2224")
In my test, I use rtpengine in db mode, i.e., db_url param is set.
Would your patch also fix the delay in that
Daniel-Constantin Mierla writes:
> I tried quickly with a rtpengine that was not running, and kamailio
> started fine and then was responding fast for sip requests.
>
> To clarify: you actually have more rtpengine configured (at least two)
> in a set and one is not available, right?
Yes, I have
David Villasmil writes:
> You could also ask politely, as this IS open source, after all.
I didn't notice any impoliteness in my message. I just mentioned that a
proper fix is needed.
-- Juha
___
Kamailio (SER) - Users Mailing List
* Paolo Visintin - evosip.cloud writes:
> we solved starting with no rtpengine this produces at startup:
> WARNING: rtpengine [rtpengine_db.c:100]: rtpp_load_db(): No rtpproxy
> instances in database
> and then, after rtpengine instances are up and correctly running we send an
>
Daniel-Constantin Mierla writes:
> Can you see the packet being sent over the network (with ngrep, tcpdump,
> ...)?
Yes, UDP register is sent, but kamailio does not respond to it.
Then I did this.
1) Started K where rtpengine udp:192.26.134.10:6050 is enabled but is
not running.
2) Gave
Daniel-Constantin Mierla writes:
> It waits for packets from the network. Did you send registration via
> UDP?
No, via tcp and there was also tcp listener processes.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
Daniel-Constantin Mierla writes:
> Can you see how many kamailio processes are running (w.g., with ps)? Are
> there expected number of there?
Same number of processes when I start K with proper rtpengine set and
with one that has an rtpengine that does not respond.
> If yes, take the PID of few
Daniel-Constantin Mierla writes:
> what happens when you send a sip message and have debug=3? Do you see
> any logs printed?
Nothing comes to syslog when register request arrives. Also kamailio does not
respond to ctl command.
Below is sample on what comes to syslog after start.
-- Juha
I noticed that if one rtpengine in a set is unreachable, kamailio 5.2
does start, but does not process any SIP requests. Is this intentional?
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
Daniel Tryba writes:
> On Mon, Nov 12, 2018 at 09:59:10AM +0100, Jos?? Antonio Guti??rrez Delgado
> wrote:
> > Hi, I would like to know if it is possible to make the last register of a
> > user the active register and if possible the only one.
> > I'm with an Android application and sometimes I
Alex Balashov writes:
> In the core, there are lots of functions such as strip(), prefix(),
> rewritehostport(), and, in my view, force_send_socket(). These functions
> don't take PV arguments, and are superceded by the more flexible direct
> manipulation of the RURI, the destination set, and
> Le 08/10/2018 à 02:27, Alex Balashov a écrit :
> > Hi,
> >
> > 1. force_send_socket() is essentially deprecated in favour of mutating
> > $fs:
> >
> > $fs = 'udp:67.215.186.219:5060';
According to wiki, $fs cannot deprecate force_send_socket.
In force_send_socket, proto can be left out:
Floimair Florian writes:
> I think your mail was intended for the baresip mailing list.
> There is no baresip.c in Kamailio
I just wanted to check if it is really so that clang doesn't generate
unused compiler warnings. Any C source is OK for that test and I just
happened to have baresip.c
I just made a test and, for sure, clang warns about unused variables:
$ clang -Wunused-variable -I/usr/include/re -I/usr/include/baresip -lbaresip
-lrem -lre baresip.c
baresip.c:48:6: warning: unused variable 'unused' [-Wunused-variable]
int unused;
^
1 warning generated.
Duarte Rocha writes:
> When Kamailio receives the INVITE, it relays it with two Record-Route like
> this :
>
> Record-Route:sip:IP1;ftag=;vst=xxx;vsf=xxx
> Record-Route:sip:IP2;ftag=;vst=xxx;vsf=xxx
> What i want is :
>
>
Daniel-Constantin Mierla writes:
> I will check the cherry pick conflict and do the backport manually if
> needed once. Going to be a bit later today.
I did it. There was only one small conflict.
-- Juha
___
Kamailio (SER) - Users Mailing List
Juha Heinanen writes:
> I'll backport to 5.1.
cherry-pick didn't work:
$ git cherry-pick -x f088d2afe4153b9e440a4293211c78f5a25af691
error: could not apply f088d2afe... core: if nosip msg hooks skip handling the
packet, stop sip routing processing
hint: after resolving the conflicts, m
Daniel-Constantin Mierla writes:
> I guess you have some modules that registered to process non-sip
> traffic, such as xhttp, xmlrpc, ... the parse_msg() throws error and in
> such case the processing is delegated to non-sip message handling, if
> all skipped, then ended up on trying going
Daniel-Constantin Mierla writes:
> Can you send all log messages with debug=3?
I also started k with debug=3 to check that the event route is ok:
Sep 17 17:00:40 char sip-proxy: DEBUG: [core/events.c:53]:
sr_core_ert_init(): event_route[core:receive-parse-error] is defined
-- Juha
Daniel-Constantin Mierla writes:
> Can you send all log messages with debug=3?
Below.
> Btw, the source ip variable is $si.
Oh yes, I had just copied the statement from other part of config,
where $si has been assigned to $var(src_ip).
-- Juha
Sep 17 16:56:07 char /usr/bin/sip-proxy[24183]:
201 - 300 of 373 matches
Mail list logo
