Module: sip-router
Branch: ser_core_cvs
Commit: 31fd952ba8af48122876ded631446e210f1634f8
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=31fd952…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Wed Mar 4 20:56:00 2009 +0000
sctp: connection reuse & connection tracking
- support for sctp connection tracking and true sctp connection
reuse for replies.
We need this to support reply connection reuse with asymmetric
sctp peers (while there is no reason not to use the same port on
sctp for sending and receiving messages and it should be
strongly discouraged to do so, we never now with what
implementation we'll have to deal).
What makes this particularly complex is the not-yet-complete
sctp API, the slight but important behaviour
differences between its linux, freebsd and solaris
implementations and the fact that is more geared towards serial
single threaded application rather then parallel-processing
multi-process or multi-threaded ones.
- keep track of the number of active and tracked sctp connections
- blacklist moved into sctp_handles_assoc_change()
---
forward.c | 11 +-
main.c | 8 +
msg_translator.c | 20 +-
sctp_server.c | 1274 +++++++++++++++++++++++++++++++++++++++++++++++++++---
sctp_server.h | 11 +
5 files changed, 1266 insertions(+), 58 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=31f…
Module: sip-router
Branch: ser_core_cvs
Commit: 7a6f43c829df5d3d2febe828581a0902fc4c10f1
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7a6f43c…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Wed Mar 4 20:55:44 2009 +0000
sctp: empty sctp_handle_assoc_change added
---
sctp_server.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/sctp_server.c b/sctp_server.c
index 9b8688f..2a7a85d 100644
--- a/sctp_server.c
+++ b/sctp_server.c
@@ -663,6 +663,24 @@ static int sctp_handle_send_failed(struct socket_info* si,
+/* handle SCTP_ASOC_CHANGE notifications: map ser global sctp ids
+ * to kernel asoc_ids. The global ids are needed because the kernel ones
+ * might get reused after a close and so they are not unique for ser's
+ * lifetime. We need a unique id to match replies to the association on
+ * which we received the corresponding request (so that we can send them
+ * back on the same asoc & socket if still opened).
+ * returns 0 on success, -1 on failure
+ */
+static int sctp_handle_assoc_change(struct socket_info* si,
+ union sockaddr_union* su,
+ int state,
+ int assoc_id)
+{
+ return -1; /* failure, not implemented */
+}
+
+
+
static int sctp_handle_notification(struct socket_info* si,
union sockaddr_union* su,
char* buf, unsigned len)
@@ -764,6 +782,8 @@ static int sctp_handle_notification(struct socket_info* si,
}
}
#endif /* USE_DST_BLACKLIST */
+ sctp_handle_assoc_change(si, su, snp->sn_assoc_change.sac_state,
+ snp->sn_assoc_change.sac_assoc_id);
break;
#ifdef SCTP_ADAPTION_INDICATION
case SCTP_ADAPTION_INDICATION:
Hi all,
i'll present in the next week the Kamailio project at the FFG 2009 conference.
Topics of my talk are:
- overview about Kamailio
- applications and usage scenarios
- new and interesting stuff in the 1.5.0 release
- future developments, the sip-router project
Date: Thursday, 12.03.2009
Place: Karlsruhe, Germany
Link to the abstract (in german as the talk will be also held in german):
http://www.guug.de/veranstaltungen/ffg2009/abstracts.html#3_2_1
More information about the event:
http://www.guug.de/veranstaltungen/ffg2009/
I'll provide the slides and eventual some notes after the talk as usual.
Cheers,
Henning
Hi, a current limitation in Kamailio (and AFAIK also in SER) is that TCP
childs block waiting for the connection being established or ended.
For example, if we run Kamailio with "tcp_children=8" and receive 8 "hacked"
INVITE's via UDP like:
INVITE sip:hello@non.responding.host1;transport=TCP SIP/2.0
INVITE sip:hello@non.responding.host2;transport=TCP SIP/2.0
INVITE sip:hello@non.responding.host3;transport=TCP SIP/2.0
...
INVITE sip:hello@non.responding.host2;transport=TCP SIP/2.0
then Kamailio will have all their TCP childs busy waiting for 8 outgoing TCP
connections to timeout. If a new request requires TCP it must wait for long
time until one of the TCP childs becomes available.
Of course this can be very easily hackeable by an attacker.
To improve it, a TCP child should not block waiting for the TCP connection to
end.
Perhaps I'm wrong (I will check it in a testing escenario soon). If not, is it
planned to improve it?
Thanks a lot.
--
Iñaki Baz Castillo