Module: sip-router
Branch: sr_3.0
Commit: 229bd1f517cb9177dc731929c31153b2b9513215
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=229bd1f…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Mon Nov 30 12:29:20 2009 +0100
presence(k): fix off-by-one memory allocation
Due to some missing '()' ( (...)?resource.len:event.len + 1
instead of ((...)?resource.len:event.len) + 1 ) sometimes the
memory allocated was less with one byte then what was needed.
The fixed version also replaces ?: with MAX_unsigned() (does the
same thing and it's easier to read).
Reported-by: Andres Moya andres.moya.i gmail com
---
modules_k/presence/notify.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/modules_k/presence/notify.c b/modules_k/presence/notify.c
index 92c2f55..6d16033 100644
--- a/modules_k/presence/notify.c
+++ b/modules_k/presence/notify.c
@@ -1793,8 +1793,7 @@ str* create_winfo_xml(watcher_t* watchers, char* version,
LM_ERR("while adding child\n");
goto error;
}
- res= (char*)pkg_malloc((resource.len>event.len)?resource.len:event.len
- + 1);
+ res= (char*)pkg_malloc(MAX_unsigned(resource.len, event.len) + 1);
if(res== NULL)
{
ERR_MEM(PKG_MEM_STR);
Module: sip-router
Branch: sr_3.0
Commit: cf1ba69f5b06fda8054da75d52a1ba187f5080e8
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=cf1ba69…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Mon Nov 30 12:02:37 2009 +0100
sctp: fix cfg.set_delayed* setting some config options immediately
- all the runtime cfg options that involve setting socket options
are now set using a per-child cfg callback with
CFG_CB_ONLY_ONCE and not in the value fixup function. This fixes
cfg.set_delayed* (up until now it did set these options
immediately and not after cfg.commit).
- init_max_timeo valid range fixed (from 0-1024 to 0-2^30).
---
sctp_options.c | 408 +++++++++++++++++++++++++++++++++++++-------------------
1 files changed, 272 insertions(+), 136 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=cf1…
Hello,
when i try to use the Permissions module with a db backend I get this error in syslog and kamailio crashes
Nov 27 13:09:48 uplink01 /usr/local/sbin/kamailio[14345]: ERROR: <core> [db.c:408]: invalid version 4 for table trusted found, expected 5 (check table structure and table "version")
Nov 27 13:09:48 uplink01 /usr/local/sbin/kamailio[14345]: ERROR: permissions [trusted.c:183]: error during table version check.
Nov 27 13:09:48 uplink01 /usr/local/sbin/kamailio[14345]: ERROR: permissions [permissions.c:617]: failed to initialize the allow_trusted function
Nov 27 13:09:48 uplink01 /usr/local/sbin/kamailio[14345]: ERROR: <core> [sr_module.c:874]: init_mod(): Error while initializing module permissions
It seems that the sql scripts wheren't updated if the table structure for the trusted table has changed
Freundliche Grüße
Mike van Stijn
Schoenland Online GmbH
Technology Operations
Professional System Engineer
Tel. 0221 / 8455-1866
Fax 0221 / 8455-2428
mike.vanstijn(a)schoenland.net
www.schoenland.net
Think before you print.
Gesetzliche Pflichtangaben:
Schoenland Online GmbH, Sitz der Gesellschaft ist Köln, Amtsgericht Köln HRB 59449, WEEE-Reg.-Nr.: DE57403598; Geschäftsführer: Daniel Schoenland, Henning Keil; Zuständige Aufsichtsbehörde: Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen Tulpenfeld 4, 53113 Bonn
Wie Sie wissen, können über das Internet versandte E-Mails leicht unter fremden Namen erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um Verständnis dafür, dass wir zu Ihrem und unserem Schutz die rechtliche Verbindlichkeit der vorstehenden Erklärungen und Äußerungen ausschließen, soweit wir mit Ihnen keine anders lautenden Vereinbarungen getroffen haben. Die für die Schoenland Online GmbH geltenden Regelungen über die Verbindlichkeit von Willenserklärungen bleiben unberührt.
Module: sip-router
Branch: master
Commit: df264708d4eb9946ce4b3f26ae8f3fe4eb4b4484
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=df26470…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Fri Nov 27 17:16:41 2009 +0100
doc: change commit requirements according the discussion on ml
---
doc/cvs-commit-rules.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/cvs-commit-rules.txt b/doc/cvs-commit-rules.txt
index 430c1bc..6fa8d74 100644
--- a/doc/cvs-commit-rules.txt
+++ b/doc/cvs-commit-rules.txt
@@ -15,14 +15,14 @@ Exceptions:
2. Code requirements
--------------------
2.1 Unstable branch:
- - the code must compile (at least on one arhitecture). If the code does not compile, but you still want to commit it, comment it out (#if 0 ... #endif)
+ - the code must compile (at least on one architecture). If the code does not compile, but you still want to commit it, comment it out (#if 0 ... #endif)
- the code should compile without warnings (with -Wall) (exceptions: very difficult to avoid warnings)
- follow SIP-router coding style
2.2. Stable branch (everything for unstable branch +)
------------------------------------------------------
- - the code must compile on all the arhitectures (this currently includes
+ - the code should compile on all the architectures (this currently includes
linux, freebsd, netbsd, openbsd, solaris >= 8; x86, ultrasparc, strongarm;
- gcc 2.95, 3.x, icc, sun cc >=5.3).
+ gcc 4.x, icc, sun cc >=5.3). It should also compile on gcc 2.95 and 3.x.
- the code must be tested or the change trivial enough
- - the code must compile without warnings on all the arhitectures (with some exceptions)
+ - the code should compile without warnings on all the arhitectures (with some exceptions)
Greetings,
I was faced with the following problem in Kamailio 1.5.2: I was using
nathelper + rtpproxy + registrar and needed to relay media for calls
going inbound to a NAT'd registrant through rtpproxy - only if the
registrant is NAT'd.
Here is the scenario:
Media gateway Kamailio
(on public IP) ----> registrar -----> NAT'd registrant
(w/nathelper)
I was handling registrations from NAT'd endpoints like this:
if(nat_uac_test("1")) {
force_rport();
fix_nated_contact();
}
I was aware of fix_nated_register() but was not clear on its
relationship to the 'received_param' parameter stored in 'location' and
set as a modparam to both the 'registrar' and 'nathelper' modules, so I
was not using it.
Very quickly I ran into an obvious problem: if the contact stored in
the 'contact' column in 'location' is already fixed up with the received
IP:port, there is no way to know that the endpoint to which the call is
going is behind NAT -- when lookup() is called, the RURI is set to the
public IP:port. There are no flags of any kind that one can set during
save() that persist while the contact binding is present for that AOR
and can be resurrected on lookup().
Anyway, I eventually figured out how to fix this problem by empirical
means, with no clear help from the nathelper documentation. It turns
out that if I set the 'received_param' as a modparam to 'nathelper' and
'registrar' and handle registrations from NAT'd endpoints with
fix_nated_register() instead, it will magically work.
I made the following discoveries to arrive at this conclusion, both of
which are not documented. This is why it will work:
1) When the original (RFC1918) 'contact' is stored in the 'location'
table (if using DB, which I am), the 'received' parameter is stored
alongside it and contains the public IP:port.
When lookup() is called, the RURI domain is set to private address, e.g.
if(!lookup("location")) {
# Error handling here
exit;
}
xlog("L_INFO", "[R-2:$ci] -> Registration resolved to RURI: $ru\n"):
$ru here will contain something like this: sip:s@10.1.0.2:5060, the
original and unmodified contact supplied by the UAC.
But somehow, magically, when t_relay() is called the request will be
relayed to a different RURI - one with the 'received' IP:port
substituted in the domain portion. So, the request goes end up going to
the correct place.
This is, of course, because of the way the 'received' parameter is
supposed to work when appended to a Contact URI. But the point is that
it is not documented; nowhere in the documentation for lookup() or
t_relay() does it say that this will transpire, and I have no way of
knowing it except by observation.
2) For some reason, nat_uac_test("1") returns a positive result after
the lookup() and confirms that the destination is NAT'd.
This allows me to set a flag and then mangle the SDP in the reply to use
rtpproxy for NAT traversal of media as well, e.g.
route[2] {
...
if(!lookup("location")) {
# Error handling here
exit;
}
if(nat_uac_test("1"))
setflag(9);
...
t_on_reply("1");
if(!t_relay())
sl_reply_error();
...
}
...
onreply_route[1] {
if(t_check_status("(180|183|200)")) {
if(nat_uac_test("5"))
fix_nated_contact();
if(search("Content-Type: application/sdp")) {
if(isflagset(9)) {
set_rtp_proxy_set("1");
force_rtp_proxy();
}
}
}
}
But if you examine carefully the documentation for nat_uac_test(), it
says the following for bit flag 1:
* 1- Contact header field is searched for occurrence of RFC1918
addresses.
To me this means that nat_uac_test() should not work after the lookup()
above. The only Contact header value that is present in the inbound
INVITE handler is the Contact URI of the media gateway, which is a
public IP address! Yet for some reason it works, as if by magic;
apparently it is somehow implicit that a hidden "received" attribute of
the RURI is also part of this check.
This is also not documented, and is completely counterintuitive.
Is there any possibility of clearing up documentation as to this point?
Perhaps I have done something wrong here unknowingly; I have no idea.
I know that my solution works but I cannot justify why in terms of the
documentation. Is it very much to ask that the documentation be
explicit about hidden but critically important mysteries like this?
Thanks!
-- Alex
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Ok, lets forward to developers?
Klaus Darilion wrote:
> Hi guys!
>
> I can reproduce the problem - I think there is a bug: nathelper's (k)
> sipping_rpl_filter function - which should absorb the replies - is not
> executed on received replies.
>
> Maybe there is problem in general with the reply callback or maybe
> there is a bug from consolidating ser's and kamailio's module interface?
>
> regards
> klaus
>
>
>
>
> Andres Moya schrieb:
>> I am using git to pull 3.0
>>
>> [root@v kamailio]# cat .git/config
>> [core]
>> repositoryformatversion = 0
>> filemode = true
>> bare = false
>> logallrefupdates = true
>> [remote "origin"]
>> url = git://git.sip-router.org/sip-router
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> [branch "kamailio_3.0"]
>> remote = origin
>> merge = refs/heads/kamailio_3.0
>>
>>
>> I can't do anything in request route?
>> [root@v kamailio]# cat /usr/local/etc/kamailio/kamailio.cfg | grep
>> nathelper
>> loadmodule "nathelper.so"
>> # ----- nathelper -----
>> #modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7722")
>> modparam("nathelper", "rtpproxy_sock", "/var/run/rtpproxy.sock")
>> modparam("nathelper", "natping_interval", 30)
>> modparam("nathelper", "ping_nated_only", 1)
>> modparam("nathelper", "sipping_bflag", 7)
>> modparam("nathelper", "sipping_from", "sip:pinger@riki.ru")
>> modparam("registrar|nathelper", "received_avp", "$avp(i:80)")
>>
>>
>> Maybe wrong with sipping_from address.
>>
>> [root@v kamailio]# cat /usr/local/etc/kamailio/kamailio.cfg | grep
>> riki.ru
>> alias=sip.riki.ru:5060
>> alias=sip.riki.ru:5070
>> modparam("presence", "server_address", "sip:sip.riki.ru:5060")
>> modparam("nathelper", "sipping_from", "sip:pinger@riki.ru")
>>
>> well it is not a server name. but! it is local in database domains,
>> and aliased. Changing to pinger@server IP...
>>
>> U 195.167.152.55:5060 -> 77.37.164.119:32788
>> OPTIONS sip:77.37.164.119:32788 SIP/2.0.
>> Via: SIP/2.0/UDP 195.167.152.55:5060;branch=0.
>> From: sip:pinger@195.167.152.55;tag=7b7af265.
>> To: sip:77.37.164.119:32788.
>> Call-ID: f2e08d27-ed2df483-8210ae1(a)195.167.152.55.
>> CSeq: 1 OPTIONS.
>> Content-Length: 0.
>> .
>>
>> #
>> U 77.37.164.119:32788 -> 195.167.152.55:5060
>> SIP/2.0 200 OK.
>> Via: SIP/2.0/UDP 195.167.152.55:5060;branch=0.
>> Contact: <sip:192.168.0.102:32788>.
>> To: <sip:77.37.164.119:32788>;tag=864a9e4d.
>> From: <sip:pinger@195.167.152.55>;tag=7b7af265.
>> Call-ID: f2e08d27-ed2df483-8210ae1(a)195.167.152.55.
>> CSeq: 1 OPTIONS.
>> Accept: application/sdp.
>> Accept-Language: en.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>> SUBSCRIBE, INFO.
>> User-Agent: X-Lite release 1103k stamp 53621.
>> Content-Length: 0.
>> .
>>
>> Nov 26 15:42:19 v /usr/local/sbin/kamailio[29793]: ERROR: <core>
>> [forward.c:695]: ERROR: forward_reply: no 2nd via found in reply
>>
>>
>>
>>
>> Klaus Darilion wrote:
>>> Never saw this yet. IIRC correctly, the responses should be consumed
>>> by nathelper module before entering the script.
>>>
>>> which version are you using?
>>>
>>> klaus
>>>
>>> Andres Moya schrieb:
>>>> Hi.
>>>>
>>>> nathelper sending empty OPTIONS messages to clients. It have only
>>>> one VIA, server's IP address(195.167.152.55). Then it got reply i
>>>> have:
>>>> U 195.167.152.55:5060 -> 81.195.165.250:5060
>>>> OPTIONS sip:81.195.165.250:5060 SIP/2.0..Via: SIP/2.0/UDP
>>>> 195.167.152.55:5060;branch=0..From:
>>>> sip:pinger@riki.ru;tag=e64c73d5..To:
>>>> sip:81.195.165.250:5060..Call-ID:
>>>> 680bed34-d2e5c741-0eff517(a)195.167.152
>>>> .55..CSeq: 1 OPTIONS..Content-Length: 0....
>>>> #
>>>> U 81.195.165.250:5060 -> 195.167.152.55:5060
>>>> SIP/2.0 200 OK..Via: SIP/2.0/UDP
>>>> 195.167.152.55:5060;branch=0..Contact: <sip:10.0.52.103:5060>..To:
>>>> <sip:81.195.165.250:5060>;tag=021c6509..From:
>>>> <sip:pinger@riki.ru>;tag=e64c73d5..Call-ID: 680bed34-d2e
>>>> 5c741-0eff517@195.167.152.55..CSeq: 1 OPTIONS..Accept:
>>>> application/sdp, application/sdp..Accept-Language: en..Allow:
>>>> INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO,
>>>> SUBSCRIBE..User-Agen
>>>> t: Zoiper rev.5324..Allow-Events: presence..Content-Length: 0....
>>>> Nov 25 23:59:26 v /usr/local/sbin/kamailio[9697]: ERROR: <core>
>>>> [forward.c:695]: ERROR: forward_reply: no 2nd via found in reply
>>>> #
>>>> U 195.167.152.55:5070 -> 86.154.150.209:5060
>>>> OPTIONS sip:86.154.150.209:5060 SIP/2.0..Via: SIP/2.0/UDP
>>>> 195.167.152.55:5070;branch=0..From:
>>>> sip:pinger@riki.ru;tag=f64c73d5..To:
>>>> sip:86.154.150.209:5060..Call-ID:
>>>> 680bed34-e2e5c741-7eff517(a)195.167.152
>>>> .55..CSeq: 1 OPTIONS..Content-Length: 0....
>>>> #
>>>> U 86.154.150.209:5060 -> 195.167.152.55:5070
>>>> SIP/2.0 404 Not Found..Via: SIP/2.0/UDP
>>>> 195.167.152.55:5070;branch=0..To:
>>>> <sip:86.154.150.209>;tag=931uruqh0thc6crbneub..From:
>>>> <sip:pinger@riki.ru>;tag=f64c73d5..Call-ID:
>>>> 680bed34-e2e5c741-7eff517(a)195.1
>>>> 67.152.55..CSeq: 1 OPTIONS..Content-Length: 0....
>>>> Nov 25 23:59:33 v /usr/local/sbin/kamailio[9698]: ERROR: <core>
>>>> [forward.c:695]: ERROR: forward_reply: no 2nd via found in reply
>>>>
>>>> Reply should be consumed by nathelper? or i should eat it
>>>> somewhere? i can't do so in request route. and i can't use reply
>>>> route because i can't set t_on_reply, it is not my request. There
>>>> should be easy way... tired get ERROR: forward_reply: no 2nd via
>>>> found in reply
>>>>
>>>> thanks
>>>>
>>>> _______________________________________________
>>>> sr-users mailing list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users