Jiri,
Thanks for your explanation, and let me know the architecture drawback of the B2BUA.
Since we have no way to choose other means to implement pre-paid, we have to go along with
B2BUA in a short term.
Could you give me any advise how to implement B2BUA based on SER and estimate the work we
should do?
Could you give me a performance estimate?
Best Regards and Thanks.
Chang Hui
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Saturday, January 04, 2003 8:29 PM
To: chang hui; serusers(a)lists.iptel.org
Subject: RE: [Serusers] About B2BUA
Hello,
I see -- prepaid scenarios are indeed difficult without a B2BUA.
There has been a proposal few times to use session timer (a proxy
looks at ballance and attaches a hint to SIP requests indicating
when a call should terminate), but the work has not been pursued.
You may find a discussion of B2BUA architectural drawbacks on the
SIP mailing list, selected postings are at
http://www.iptel.org/info/trends/#b2bua.
imho, the most compelling issue is that of robustness and scalability.
A b2bua needs to keep track of all current calls. A broken b2bua affects
signaling for all existing calls.
Basically, a B2BUA is simply two UAs glued together. It accepts
transactions as a server, and initiates client transactions
based on them. It keeps dialog state (callid, cseqs, etc.) and
may initiate in-dialog transactions on its own (like the BYE
transaction in which you are interested).
It is doable to implement a B2BUA on top of ser, but it would
cost quite some development effort. Particularly, it would take
dialog maintenance (better with persistency so that signaling
does not get broken on reboot). We can provide guidanance to
volunteers willing to go through this exercise.
-Jiri
At 02:28 AM 1/4/2003, chang hui wrote:
Jiri,
Thanks for your prompt response.
We want to implement a pre-paid system in which once subscriber's balance is depleted,
the dialog could be torn in time. However other Proxy or other elements could not take
part in the call, they could not send a BYE to caller directly. It's the why we
consider B2BUA.
We project to build a B2BUA to support voice/video/IM at first stage, and support other
SIP based services as they emerged.
However, I just noticed the definition of B2BUA in 2543-bis04 in several sentences, there
has no other analysis on performance, reliability, limitations and how to implement it.
So, I hope to get help from the society.
Thanks for your help again.
Koalas
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Friday, January 03, 2003 11:06 PM
To: chang hui; serusers(a)lists.iptel.org
Subject: Re: [Serusers] About B2BUA
Hello,
ser is not a B2BUA -- it can act as proxy, redirect, transactional UAS
or registrar. These modes make a vast majority of network scenarios
happy without a need to use a B2BUA. Which is good, because B2BUAs
inherently have certain scalability, reliability and security limitations.
Is there a particular reason why you would like to use a B2BUA?
-Jiri
At 08:00 AM 1/3/2003, chang hui wrote:
Hi All,
I am newbie of this field, thanks everyone help me.
I am interesting in B2BUA, however, except some brief defination in 3261, I could not find
any further defination or how to implement about B2BUA, I noticed that SER could be
implemented as a B2BUA, where can I find some implementation? or where can I get any
description?
Koalas
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan
http://iptel.org/~jiri/
--
Jiri Kuthan
http://iptel.org/~jiri/