Hi Daniel,
I know you were thinking of looking at the MSRP module before the next
release, and during discussions here at Crocodile we realised that there
was another enhancement that would be useful.
An MSRP relay has the option of splitting large MSRP messages (including
those that are already chunked) into smaller chunks. The reason is that
there is no maximum size for an MSRP chunk, so it is entirely possible
for a client to attempt to send a large file in a single, very-large,
MSRP message. In this cases it becomes important to pull the message
from the receive buffer in small pieces (instead of waiting for a
complete message to arrive and over-flowing the receive buffer) and
relaying it in smaller chunks.
Also, the flow control for MSRP is based around TCP windowing, so if you
want to limit the rate that someone is sending you MSRP messages (for
example during the transfer of a large file) you do so by pulling from
the TCP buffer at a lower rate. One way of avoiding overloading an MSRP
relay is to have fairly small TCP receive buffers thereby limiting the
rate at which clients and relays can send data. However, if the TCP
buffers are small the chances of a client sending a message or chunk
that is too large (and needs to be chunked by the relay) increases
further.
Of course, to do this the MSRP module will need to be able to remember
the (From|To)-Path, transaction ID, and so on from the start of the MSRP
message so that it can use these (along with calculated Byte-Range) in
each additional chunk.
I was thinking a new parameter indicating the maximum MSRP send chunk
size is required. If an MSRP message in the receive buffer reaches that
number then it has to be pulled from the buffer in parts and relayed as
multiple chunks. This maximum send chunk size should be set to be much
smaller than the TCP receive buffer size.
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Hello,
I see that xhttp_pi module depends on libxml2, but it is compiled and
installed by default. It should be added in the excluded modules list.
Regarding packaging, perhaps its place is in xml-modules package.
Also, it installs a dedicated config file from the core Makefile. It is
no longer the proper way to do it. Each module can install additional
config file once they are installed. See the Makefile of the tls module,
which installs tls.cfg only when the module is installed as well. It
should be done for xhttp_pi module in the same way.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Module: sip-router
Branch: master
Commit: 5871982d3c76a4b42cd05e4b8dfb0e6128acb799
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5871982…
Author: Andrew Mortensen <admorten(a)isc.upenn.edu>
Committer: Andrew Mortensen <admorten(a)isc.upenn.edu>
Date: Tue Dec 4 17:04:11 2012 -0500
sca: fix DB updates
- if a subscription were updated before being inserted into the DB, the
next DB sync call would incorrectly try to UPDATE instead of INSERT.
- no effect on SCA functionality, but subscriptions are no longer lost
across restarts.
---
modules/sca/sca_subscribe.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/modules/sca/sca_subscribe.c b/modules/sca/sca_subscribe.c
index 16368e3..54331ef 100644
--- a/modules/sca/sca_subscribe.c
+++ b/modules/sca/sca_subscribe.c
@@ -826,8 +826,10 @@ sca_subscription_update_unsafe( sca_mod *scam, sca_subscription *saved_sub,
saved_sub->dialog.notify_cseq += 1;
saved_sub->expires = time( NULL ) + update_sub->expires;
- /* flag subscription for write back to DB */
- saved_sub->db_cmd_flag = SCA_DB_FLAG_UPDATE;
+ /* flag subscription for DB update only if we've already inserted */
+ if ( saved_sub->db_cmd_flag == SCA_DB_FLAG_NONE ) {
+ saved_sub->db_cmd_flag = SCA_DB_FLAG_UPDATE;
+ }
if ( update_sub->index != SCA_CALL_INFO_APPEARANCE_INDEX_ANY ) {
saved_sub->index = update_sub->index;