SEMS is another option for a B2BUA, though all its prebuilt B2BUA apps are not pure B2BUA but incorporate some sort of initial media-based announcement premise. But you can use its Python or C++ API to create one.
Another option is YATE? -- Sent from mobile device On Oct 23, 2009, at 8:07 PM, Iñaki Baz Castillo <i...@aliax.net> wrote: > El Sábado, 24 de Octubre de 2009, Jeff Kronlage escribió: >> I follow this, but -and please correct me where I'm >> misunderstanding- isn't >> the point of using a Proxy versus a B2BUA is that it's more >> lightweight >> and scalable? > > Of course, but if you want PBX features you need a B2BUA. Also, > trasferring a > call from a SIP PSTN provider does require *always* a B2BUA (in fact > the user > doesn't transfer the provider, but the B2BUA which will accept such > REFER). > > > >> It seems with this setup every call ends up routed through >> Asterisk on the initial INVITE, simply so that when a REFER >> potentially >> comes later in the dialog, it can handle it. > > If you need a proxy use a proxy. If you need a PBX you need a PBX/ > B2BUA. If > you need a very scalable system with high load you can scale it with > a proxy > in front of various PBX's (of course, most probably the PBXs won't > share > dialog inforamtion between them...). > > >> Our setup has been initially >> engineered for thousands of concurrent calls, and we're hoping to >> avoid >> having a dozen Asterisk machines :) > > What you are looking for is the dream all want: a scalable SIP B2BUA > (no media > handling), so a cluster of these B2BUA's would be located behind a > proxy > (which does load balancing and failover). And it would be greater if > the B2BUA > share information (about current dialogs and so) in some way > (memcache? common > database?...). > > You could implement it with SipServlets (see Sailin SIP application > server or > others), or FreeSwitch which allows calls without handling the > media... > Of course, Asterisk is not the most suitable solution: it involves > media > handling ("canreinvite" is a hack), it has a very poor SIP stack... > and > basically it's designed to be a single PBX box. > > >> Our goal is to design something like: >> >> UA <--> Opensips <--> Our PSTN gateways >> >> That could dynamically turn into, on the fly: >> >> UA <--> Opensips <--> B2BUA <--> Our PSTN Gateway >> >> We haven't found a clean way of doing this, unfortunately... It >> may just >> end up being a hack on Opensips 1.6 if that might work. > > You shouldn't expect that OpenSIPS could behave as a PBX because > it's a proxy. > And what you need is a PBX, you MUST assume it. A proxy is very > scalable, fast > and so, but it will NEVER provide PBX features (as transferring a > call coming > from a PSTN provider to other user). > IMHO OpenSIPS b2bua module will be useful for some limited tasks > (topology > hidding and others) but not for replacing a PBX. > > > > Regards. > > > > -- > Iñaki Baz Castillo <i...@aliax.net> > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users