Andreas Granig wrote:
On 10/28/2010 09:07 PM, Alex Balashov wrote:
While we believe that SBCs are one of the things the world does not
really need, apparently some marketing departments have convinced the
world otherwise.
No truer a statement ever made.
Well, I'm still not quite sure what makes a B2BUA an SBC (it probably
just sounds more professional :) ), but in the real world, B2BUAs become
probably.
support for multiple interfaces has been mentioned to me, that makes
it possible to physically seperate the networks.
very handy from time to time. Lots of UAs are still pretty broken when
it comes to processing larger (~ >5) Via/Route/Record-Route sets (I'm
looking at you, Cisco). In such cases, chances are high to also exceed
the MTU size, and with fragmentation all this broken SOHO NAT devices
add themselves to the game.
good points. as sems does not support tcp (and ratelimit etc), I
suppose that in most cases one edge proxy will be used anyway, but one
proxy in the path should not cause any problems I guess.
So from my perspective, I highly appreciate your efforts, Stefan!
This is a very exciting development and I am thrilled to hear of it! I
will definitely contribute to testing.
We're using sippy b2bua in some deployments, where we currently
implement transaction and dialog persistence using redis as a backend,
since it's simple, fast, easy-to-use and offers replication. Thus, you
can replicate states to a standby server and from there continue
processing active transactions and dialogs after a fail-over. Are there
any plans for such a thing on the road-map for sems? Do you see any
show-stoppers implementing this? Either way, I'll definitely have a look
we have implemented replication to and failover from a backup server
(in a private branch). so, no, no real show-stoppers there. we are
using sems' internal in-mem db (monitoring), so only active-passive is
supported with replication to one backup server. looks like redis fits
quite well, too, even though i'm not really convinced that it's worth
using an external process for storing the dialog/session checkpoint.
otoh redis' support for replication is of course more advanced.
we also implemented re-establishing the session from the backup (using
reinvite), but i'm not sure whether in real-world failure detection
and fail-over is fast enough to keep calls going as there's always
some seconds gap in the RTP.
BR
Stefan
at it to get rid of sippy.
Andreas
------------------------------------------------------------------------
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
--
Stefan Sayer
VoIP Services Consulting and Development
Warschauer Str. 24
10243 Berlin
tel:+491621366449
sip:[email protected]
email/xmpp:[email protected]
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
