El Viernes, 28 de Noviembre de 2008, Stefan Sayer escribió: > 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.
Thanks for so complete explanation. -- Iñaki Baz Castillo _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
