RE: [Serusers] About B2BUA

At 10:00 AM 1/6/2003, chang hui wrote: I've already done so in my previous email. If something was not clear enough, let me know. A hand-waving guestimate is performance degrades by 50%. (We currently achieve up to 3-5 kCPS on a PC -- fair capacity to slice off from.). a B2BUA does a lot of things: - first, it keeps dialog state -- it rememembers cseq, callid, route set, etc. for the whole time of a call (i.e., it eats memory). All this information is needed when you later wish to initiate correct BYEs. - it translates UAC to UAS transactions and vice versa - you probably want to save the dialog state on some persistence storage (mysql) -- signaling would not work on reboot otherwise That would take quite some development work. I think the amount of work can be somewhat lowered if normal (record-routed) proxy processing is used, as opposed to a full B2BUA which terminats all UAS transactions and translates them to UAC transactions. You then still need to do the following: - keeping a dialog table (keyed by callid and local/remote tags) - updating the dialog table (new items on INVITE completion, remove dialogs on BYE, update dialog state, such as CSeq, on any other request). - starting a timer on beginning of a dialog that -- when expired, subject to balance and charging plans -- sends BYEs to all call parties using dialog context. That could be implemented as a new ser module, which registers TM-module callbacks to be updated on transactions completions. One could also move the dialog maintenance out of ser to some shell scripts to make programming easier. That would however very likely degrade performance noticeably. Also note, that these scenarios are based only on signaling -- there are no PSTN-prepaid-style anouncement "you can call 5 minutes" and "your call will be cut off in 20 seconds". It is doable too, but it is probably more meaningful to start with the signaling part. -Jiri -- Jiri Kuthan http://iptel.org/~jiri/