Hello,
If we want to make the sip-router core usable in both projects, we would also
need to merge both tls implementations. In SER we moved the the TLS
implementation into tls module.
In Kamailio it appears that the tls implementation is in tls subdirectory in
the core and then there is tlsops module which contains pseudovariables used
to retrieve information from TLS certificates.
Unless somebody has a better idea, I would propose that we merge the tls
implementation from kamailio core into ser tls module. In addition to that we
could merge the implementation of tls related pseudovariables from tlsops into
the tls module and then put the tls module into the sip-router repository.
What do you think? I volunteer to do this if nobody objects.
Jan.
Hi,
We've reached the point where we should start adding modules. Me and Jan
would like to start moving ser modules to sip-router. ser modules are
particularly easy because we can move changes from ser cvs
semi-automatically (only a git pull required), so we don't need to stop
development on cvs.
Soon we will have to add kamailio modules too, but for kamailio it would
be more painful, both because of the bigger number of changes required
and because it's difficult to update from svn (so it would be better if
all developers would move to git or use patches).
We must decide if we use separate repositories or a branch in sip-router and
we should also start thinking about the version number of the first ser
and first kamailio based on sip-router.
Repositories:
1. we use branches inside sip-router:
master - like now, only core, tm and common modules
ser_30 - master merged with ser_modules, next version of ser will
come out of it
kamailio_30 - same like above
Disadvantages: - one big repo
- people must be careful _not_ to merge ser_30 or
kamailio_30 into master (that would bring all the
modules into master which is not what we want)
- if someone working on the ser_30 branch (for example)
finds a problem in the core and wants to fix it, it
has to do it on the master branch.
- if the above requirement cannot be avoided and someone
does a specific core change in ser_30 or k_30
(e.g. name in makefile), it should always do it in a
separate commit (no commits touching both core/tm and
some project specific module, instead separate
commits for the common part so that they might be
cherry-picked)
2. we use 3 repositories:
sip-router - like now, only the common part: core, tm and common
modules
ser-ng - sip-router + ser modules
kamailio-ng - sip-router + k modules
Advantages: - 3 smaller repos
- more difficult to make mistakes and merge kamailio or
ser into sip-router/master
Disadvantages: - 3 smaller repos :-)
- same as for (1)
In general whatever we can do with branches in the same repo we can with
branches in different repos, so a complete kamailio-ser merge would not
be affected if we use separate repos.
Version numbers:
I think it would be a good idea to come up with a versioning scheme that
would reflect the common part used for future ser and kamailio releases.
Maybe 3.x (3 being > then both current ser and kamailio version), or
mabye v.v.X , where v.v is the sip-router version (common part) and X is
the project version (ser or kamailio).
What's important is to (very) quickly decide on the repository layout (because
this will slow us down) and on the names for the branches or for the different
repos. Once this is decided we want to quickly make a test ser version based
on sip-router and start testing it. If everything looks ok we want to
start using it on iptel.org.
Andrei
Hello all,
The SDP parser from the kamailio core needs to be imported into the
sip-router core.
It is located under parser/sdp directory.
Th qos module has a dependency on the SDP parser.
Regards,
Ovidiu Sas
Module: sip-router
Branch: master
Commit: 7a0489e835789292fbe133b2000bc4091db87e5b
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7a0489e…
Author: Jan Janak <jan(a)iptel.org>
Committer: Jan Janak <jan(a)iptel.org>
Date: Fri Feb 27 23:27:37 2009 +0100
Merge branch 'ser_core_cvs'
* ser_core_cvs:
sctp: direct blacklist support
Support for MESSAGE and OPTIONS method types are added to the parser.
log/dbg: level is not limited anymore
config: tcp_async alias for tcp_buf_write
tcp: async write timeout fixes
tcp: blacklist at tcp level if possible
blst: another blacklist dest. function version
cfg_size macro renamed to cfg_sizeof to avoid a conflict with one of the
Conflicts:
cfg.y
The first conflict in BREAK definition, the file coming from cvs contained
RETURN_R_F, while the file coming from git contained BREAK_R_F, I resolved it
with BREAK_R_F.
The second conflict was in the definition in LOG_TOK which was resolved with
the latest version from cvs.
---
Module: sip-router
Branch: master
Commit: 047b1dfb8958f4ba29fd77ed44e7cb17fdd106b1
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=047b1df…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Fri Feb 27 21:15:27 2009 +0000
sctp: direct blacklist support
- blacklist support at the sctp level. If sctp_send_retries are
used, the blacklist will work only for send (using
SCTP_SEND_FAILED notifications). If sctp_send_retries is not
used (default), there are 2 possible blacklist reasons: SEND or
CONNECT (assoc. failed to be opened).
---
sctp_server.c | 31 ++++++++++++++++++++++++++++++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/sctp_server.c b/sctp_server.c
index 7ac8444..9b8688f 100644
--- a/sctp_server.c
+++ b/sctp_server.c
@@ -22,6 +22,7 @@
* History:
* --------
* 2008-08-07 initial version (andrei)
+ * 2009-02-27 blacklist support (andrei)
*/
#ifdef USE_SCTP
@@ -49,6 +50,9 @@
#include "mem/mem.h"
#include "ip_addr.h"
#include "cfg/cfg_struct.h"
+#ifdef USE_DST_BLACKLIST
+#include "dst_blacklist.h"
+#endif /* USE_DST_BLACKLIST */
@@ -643,6 +647,16 @@ static int sctp_handle_send_failed(struct socket_info* si,
ret=sctp_msg_send_raw(&dst, data, data_len, &sinfo);
}
+#ifdef USE_DST_BLACKLIST
+ else if (cfg_get(core, core_cfg, use_dst_blacklist) &&
+ sctp_options.sctp_send_retries) {
+ /* blacklist only if send_retries is on, if off we blacklist
+ from SCTP_ASSOC_CHANGE: SCTP_COMM_LOST/SCTP_CANT_STR_ASSOC
+ which is better (because we can tell connect errors from send
+ errors and we blacklist a failed dst only once) */
+ dst_blacklist_su(BLST_ERR_SEND, PROTO_SCTP, su, 0);
+ }
+#endif /* USE_DST_BLACKLIST */
return (ret>0)?0:ret;
}
@@ -665,7 +679,7 @@ static int sctp_handle_notification(struct socket_info* si,
text " too short (%d bytes instead of %d bytes)\n", \
su2a((from_su), sizeof(*(from_su))), \
(bind_addr)->name.len, (bind_addr)->name.s, \
- (bind_addr)->port_no, (length), (val)); \
+ (bind_addr)->port_no, (int)(length), (int)(val)); \
goto error; \
}
@@ -735,6 +749,21 @@ static int sctp_handle_notification(struct socket_info* si,
snp->sn_assoc_change.sac_outbound_streams,
snp->sn_assoc_change.sac_inbound_streams
);
+#ifdef USE_DST_BLACKLIST
+ /* blacklist only if send_retries is turned off (if on we don't
+ know here if we did retry or we are at the first error) */
+ if (cfg_get(core, core_cfg, use_dst_blacklist) &&
+ (sctp_options.sctp_send_retries==0)){
+ switch(snp->sn_assoc_change.sac_state) {
+ case SCTP_CANT_STR_ASSOC:
+ dst_blacklist_su(BLST_ERR_CONNECT, PROTO_SCTP, su, 0);
+ break;
+ case SCTP_COMM_LOST:
+ dst_blacklist_su(BLST_ERR_SEND, PROTO_SCTP, su, 0);
+ break;
+ }
+ }
+#endif /* USE_DST_BLACKLIST */
break;
#ifdef SCTP_ADAPTION_INDICATION
case SCTP_ADAPTION_INDICATION:
Module: sip-router
Branch: master
Commit: 38429f23ff8a73c16c1b02812fa4a27cf28c0cb1
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=38429f2…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Thu Feb 26 23:13:22 2009 +0000
tcp: blacklist at tcp level if possible
- automatically blacklist destinations if connecting to them fails
(BLST_ERR_CONNECT) or send fails (BLST_ERR_SEND), either due to a
protocol error (RST, protocol level timeout a.s.o), or because
of a ser level send/connect timeout.
Note: in this cases the sip_msg parameter of the blacklist will
be null (since in general the message triggering the error is not
known), so if you register a blacklist callback you should make
sure it works with null sip_msgs too.
- if a connection is in a connect pending state (S_CONN_CONNECT)
and something is read on it, move it into established state
(S_CONN_OK). This can happen only in tcp async mode.
- fix transition directly to S_CONN_OK from S_CONN_PENDING (should go
through S_CONN_CONNECT first)
---
tcp_main.c | 120 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
tcp_read.c | 27 ++++++++++++-
2 files changed, 139 insertions(+), 8 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=384…