Hi,
o Iñaki Baz Castillo [11/28/08 11:10]:
Hi, as I already asked, I'm interested in a transparent B2BUA with
SessionTimers in both legs. SEMS already allows it easily (it's a perfect
transparent B2BUA and implements SS, it's ajust a matter of mixing some
code).
But I wonder if, anyway, SEMS is appropiate for it. I don't want media
services, IVR, leg_b authorization, announcements... just transparent B2BUA
and SS. It would complement a SIP proxy so the mix would become a call
statefull "SIP thing".
Obviously the proxy (*SER) is very faster ahndling transaction, how faster
would be SEMS as transparent B2BUA?
run some load tests, only then you can really tell.
Could it be more appropiate to code a simple B2BUA from scratch using some
available SIP stack (as PJSip and so)?
you will have to compare how different SIP stacks implement things (e.g.
how timers are implemented, full vs. partial and early vs. lazy parsing,
etc) and how much SIP related features they provide. then you have some
architectural decisions: whether/how you do parallel processing,
threads/locking/event passing etc.
SEMS' SIP stack's timers implementation compares favourably, i have been
told. I think it parses all headers, and then collapses the not relevant
ones (due to compatibility reasons with old unixsock ctrl). How much
time is spent with this, should be a good case for kcachegrind. In SEMS,
every dialog has its thread, which works on its event queue; for b2bua
events are passed between the two threads. from my tests i have seen
that locking of event queues is not a bottleneck, even with signaling
only applications. If you have an application with media, it makes
sense to spend one thread per session, because you won't have more than
10k sessions on one server anyway (limited network bw), and you simplify
application development by preventing different sessions to block each
other (e.g. doing some DB or other synchronous external request), one
can doubt if that makes sense for a 'dialog aware proxy' type of
application.
Whether the abstraction layers by OO with polymorphism style suits your
concept of software depends on personal taste I would say, i like things
being structured this way. Using STL has its drawbacks, but i guess that
e.g. the map implementation (used to look up session for a request etc)
performs quite well, and it is just very convenient.
Apart from these considerations, obviously a proxy like *ser is much
more optimizied, but if you put the dialog layer and then the b2bua on
top you should design your architecture carefully if you don't want to
loose the good performance. for example, the performance difference for
signaling comparing an (earlier) ser+binrpc with sipctrl is 3-10x.
Stefan
Thanks a lot for your opinions.
--
Stefan Sayer
VoIP Services
[EMAIL PROTECTED]
www.iptego.com
IPTEGO GmbH
Am Borsigturm 40
13507 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
