Hi!
What is the suggested way to build sr with TLS?
Is it "TLS=1 make" or "TLS_HOOKS=1 make" or do I have to just remove tls
from excluded modules? Or a combination? I think there is some cleanup
needed as well.
regards
klaus
Module: sip-router
Branch: master
Commit: 249df0253d2ef8fa3948ce50a4a76ba8f256fd1e
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=249df02…
Author: Miklos Tirpak <miklos(a)iptel.org>
Committer: Miklos Tirpak <miklos(a)iptel.org>
Date: Wed Jul 1 14:23:09 2009 +0200
cfg framework: documentation for cfg_read_var*
- How to read the variables of another module, core, or
the script is documented.
- cfg_read_var() fixed -- it did not allow reading the variables
that had a fixup function.
---
cfg/cfg_select.c | 7 -------
doc/cfg.txt | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/cfg/cfg_select.c b/cfg/cfg_select.c
index 45aeb94..4374aa6 100644
--- a/cfg/cfg_select.c
+++ b/cfg/cfg_select.c
@@ -274,13 +274,6 @@ int read_cfg_var_fixup(char *gname, char *vname, struct cfg_read_handle *read_ha
return 0;
}
- if (var->def->on_change_cb) {
- /* fixup function is defined -- safer to return an error
- than an incorrect value */
- LOG(L_ERR, "ERROR: read_cfg_var_fixup(): variable cannot be retrieved\n");
- return -1;
- }
-
read_handle->group = (void *)group;
read_handle->var = (void *)var;
return 1;
diff --git a/doc/cfg.txt b/doc/cfg.txt
index 19b0e53..93d2c77 100644
--- a/doc/cfg.txt
+++ b/doc/cfg.txt
@@ -166,6 +166,45 @@ cfg_get(foo, cfg_handle, s)
cfg_get(foo, cfg_handle, p)
+It is also possible to access the variables of other modules or the core in two
+different ways:
+
+1) Include the header file of the other module/core that declares the cfg_group_*
+structure and the handle for it. Than use the handle of that module/core to access
+the variable:
+
+cfg_get(bar, cfg_handle_of_bar, j);
+
+2) Access the variables by their group and variable name:
+
+#include "../../cfg/cfg_select.h"
+
+struct cfg_read_handle var_bar_j;
+
+in the module init function:
+static int mod_init(void)
+{
+ if ((read_cfg_var_fixup("bar", "j", &var_bar_j)) < 0)
+ return -1;
+ /* Note that the variable may or may not exist at this point
+ * depending on the module loading order. The fixup will still
+ * be successful but the variable cannot be read if it has not been
+ * declared yet. If the variable will not be declared at all
+ * SER will fail to start
+ */
+}
+
+int j;
+if ((cfg_read_var_int(&var_bar_j, &j)) < 0) { error... }
+
+or similarly,
+str s;
+if ((cfg_read_var_str(&var_bar_j, &s)) < 0) { error... }
+
+2) is a bit slower than 1) because the first solution returns the pointer directly
+to the variable, but 2) supports also the variables declared in the script that are
+not known at compile time.
+
3. Using the framework in the core
===============================================================================
Revision: 5888
http://openser.svn.sourceforge.net/openser/?rev=5888&view=rev
Author: ibc_sf
Date: 2009-07-01 11:31:07 +0000 (Wed, 01 Jul 2009)
Log Message:
-----------
- Some typos in "is_method()" function.
Modified Paths:
--------------
trunk/etc/kamailio.cfg
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
Revision: 5887
http://openser.svn.sourceforge.net/openser/?rev=5887&view=rev
Author: ibc_sf
Date: 2009-07-01 11:28:21 +0000 (Wed, 01 Jul 2009)
Log Message:
-----------
- Fixed registration behind NAT (missing "setbflag(6)"). Credits to Rub?\195?\169n Rojas (sr-users-es).
Modified Paths:
--------------
trunk/etc/kamailio.cfg
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
Hi all,
i'm pleased to announce that i give a talk about the kamailio project on
the linuxtag 2009 in Berlin.
The title of the talk is "Building carrier grade voice over IP systems
with kamailio", on wednesday the 24th june afternoon. Further details can
be found in the conference program at:
http://www.linuxtag.org/2009/de/program/freies-vortragsprogramm/mittwoch/vo…
I'll be also present on the linuxtag on thursday, so if you would like to
meet for some discussions, just drop me a mail (off-list).
With best regards,
Henning Westerholt
Bugs item #2814137, was opened at 2009-06-29 19:29
Message generated for change (Comment added) made by marcushunger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2814137&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marcus Hunger (marcushunger)
Assigned to: Nobody/Anonymous (nobody)
Summary: force_rtp_proxy bug
Initial Comment:
force_rtp_proxy seems to handle re-invite wrong, resulting in one-way-audio.
----------------------------------------------------------------------
>Comment By: Marcus Hunger (marcushunger)
Date: 2009-07-01 11:14
Message:
sdp is in invite and 200 ok. the thing is, nearly the same config still
worked in 1.2-branch, but after an upgrade to 1.4 it stopped.
it happens always, no matter if the callee or caller does the reinvite.
the following trace shows what happens. the rtpproxy-port in invite and
reply is 41324. they must differ as they are used for different
media-streams.
217.10.1.1 - sip-proxy & rtpproxy
172.20.21.2 - sip-proxy doing rtpproxy_* stuff
217.10.66.165 - uac
217.10.1.2 - uas
U 217.10.1.1:5060 -> 172.20.21.2:5060
INVITE sip:3993942p0@217.10.1.2 SIP/2.0.
Via: SIP/2.0/UDP 217.10.1.1:5060;branch=z9hG4bK78fccbad7757B75A.
Via: SIP/2.0/UDP
192.168.234.24;rport=61020;received=217.10.66.165;branch=z9hG4bK78fccbad7757B75A.
From: "Erika" <sip:3993942e1@sipgate.de>;tag=D6DBB0FD-C198C6EA.
To: <sip:10@sipgate.de;user=phone>;tag=as3804b1ae.
Route: <sip:172.20.21.2;lr=on>.
CSeq: 4 INVITE.
Call-ID: e521bbee-f129e0af-f6e95884(a)192.168.234.24.
Contact: <sip:3993942e1@217.10.66.165:61020>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
NOTIFY, PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_650-UA/2.1.2.0078.
Supported: 100rel,replaces.
Allow-Events: talk,hold,conference.
Max-Forwards: 69.
Content-Type: application/sdp.
Content-Length: 297.
X-hint: rr-enforced.
X-nathint: nat.
.
v=0.
o=- 1246290867 1246290869 IN IP4 192.168.234.24.
s=Polycom IP Phone.
c=IN IP4 192.168.234.24.
t=0 0.
m=audio 2262 RTP/AVP 9 0 8 18 101.
a=sendrecv.
a=rtpmap:9 G722/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=direction:active.
#
U 172.20.21.2:5060 -> 217.10.1.1:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP 217.10.1.1:5060;branch=z9hG4bK78fccbad7757B75A.
Via: SIP/2.0/UDP
192.168.234.24;rport=61020;received=217.10.66.165;branch=z9hG4bK78fccbad7757B75A.
From: "Erika" <sip:3993942e1@sipgate.de>;tag=D6DBB0FD-C198C6EA.
To: <sip:10@sipgate.de;user=phone>;tag=as3804b1ae.
CSeq: 4 INVITE.
Call-ID: e521bbee-f129e0af-f6e95884(a)192.168.234.24.
Content-Length: 0.
.
#
U 172.20.21.2:5060 -> 217.10.1.2:5060
INVITE sip:3993942p0@217.10.1.2 SIP/2.0.
Via: SIP/2.0/UDP 172.20.21.2;branch=z9hG4bKe2fc.9dcfa89.0.
Via: SIP/2.0/UDP 217.10.1.1:5060;branch=z9hG4bK78fccbad7757B75A.
Via: SIP/2.0/UDP
192.168.234.24;rport=61020;received=217.10.66.165;branch=z9hG4bK78fccbad7757B75A.
From: "Erika" <sip:3993942e1@sipgate.de>;tag=D6DBB0FD-C198C6EA.
To: <sip:10@sipgate.de;user=phone>;tag=as3804b1ae.
CSeq: 4 INVITE.
Call-ID: e521bbee-f129e0af-f6e95884(a)192.168.234.24.
Contact: <sip:3993942e1@217.10.66.165:61020>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
NOTIFY, PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_650-UA/2.1.2.0078.
Supported: 100rel,replaces.
Allow-Events: talk,hold,conference.
Max-Forwards: 68.
Content-Type: application/sdp.
Content-Length: 315.
X-hint: rr-enforced.
X-nathint: nat.
.
v=0.
o=- 1246290867 1246290869 IN IP4 192.168.234.24.
s=Polycom IP Phone.
c=IN IP4 217.10.1.1.
t=0 0.
m=audio 41324 RTP/AVP 9 0 8 18 101.
a=sendrecv.
a=rtpmap:9 G722/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=direction:active.
a=nortpproxy:yes.
#
U 217.10.1.2:5060 -> 172.20.21.2:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
172.20.21.2;branch=z9hG4bKe2fc.9dcfa89.0;received=172.20.21.2.
Via: SIP/2.0/UDP 217.10.1.1:5060;branch=z9hG4bK78fccbad7757B75A.
Via: SIP/2.0/UDP
192.168.234.24;rport=61020;received=217.10.66.165;branch=z9hG4bK78fccbad7757B75A.
From: "Erika" <sip:3993942e1@sipgate.de>;tag=D6DBB0FD-C198C6EA.
To: <sip:10@sipgate.de;user=phone>;tag=as3804b1ae.
Call-ID: e521bbee-f129e0af-f6e95884(a)192.168.234.24.
CSeq: 4 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Contact: <sip:3993942p0@217.10.1.2>.
Content-Length: 0.
.
#
U 217.10.1.2:5060 -> 172.20.21.2:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
172.20.21.2;branch=z9hG4bKe2fc.9dcfa89.0;received=172.20.21.2.
Via: SIP/2.0/UDP 217.10.1.1:5060;branch=z9hG4bK78fccbad7757B75A.
Via: SIP/2.0/UDP
192.168.234.24;rport=61020;received=217.10.66.165;branch=z9hG4bK78fccbad7757B75A.
From: "Erika" <sip:3993942e1@sipgate.de>;tag=D6DBB0FD-C198C6EA.
To: <sip:10@sipgate.de;user=phone>;tag=as3804b1ae.
Call-ID: e521bbee-f129e0af-f6e95884(a)192.168.234.24.
CSeq: 4 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Contact: <sip:3993942p0@217.10.1.2>.
Content-Type: application/sdp.
Content-Length: 329.
.
v=0.
o=root 647471219 647471221 IN IP4 217.10.1.2.
s=sipgate VoIP GW.
c=IN IP4 217.10.1.2.
t=0 0.
m=audio 17732 RTP/AVP 8 0 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
##
U 172.20.21.2:5060 -> 217.10.1.1:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 217.10.1.1:5060;branch=z9hG4bK78fccbad7757B75A.
Via: SIP/2.0/UDP
192.168.234.24;rport=61020;received=217.10.66.165;branch=z9hG4bK78fccbad7757B75A.
From: "Erika" <sip:3993942e1@sipgate.de>;tag=D6DBB0FD-C198C6EA.
To: <sip:10@sipgate.de;user=phone>;tag=as3804b1ae.
Call-ID: e521bbee-f129e0af-f6e95884(a)192.168.234.24.
CSeq: 4 INVITE.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces, timer.
Contact: <sip:3993942p0@217.10.1.2>.
Content-Type: application/sdp.
Content-Length: 347.
.
v=0.
o=root 647471219 647471221 IN IP4 217.10.1.2.
s=sipgate VoIP GW.
c=IN IP4 217.10.1.1.
t=0 0.
m=audio 41324 RTP/AVP 8 0 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
a=nortpproxy:yes.
----------------------------------------------------------------------
Comment By: Klaus Darilion (klaus_darilion)
Date: 2009-07-01 08:53
Message:
do you have a SIP trace? Is it maybe related to late offer (SDP in 200 OK
and ACK)? Does the bug happens always or only if the reINVITE is sent by
the callee?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-06-30 15:15
Message:
in detail, the sdp is rewritten with the wrong port for this direction of
the session. it's the same as the answer's which does not work. to build
the query for the rtp-proxy from- and to-tag the have to be reversed in
this case.
----------------------------------------------------------------------
Comment By: Marcus Hunger (marcushunger)
Date: 2009-06-30 11:45
Message:
happens when i handle a reinvite with rtpproxy_offer("l")
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-06-29 20:19
Message:
When is this happening?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2814137&group_…