Development -> Sand Box -> B2BUA

How it should be used?

Emmanuel BUU's proposal

1. In the proxy part, we should have a new 'core?) function that would engage the B2BUA but message could be modified / twicked before getting into b2bua. It would be the configuration's responsibility to properly call this new function.

ex:

if (is_method("INVITE") && ...) b2bua_process(route_number) The function would pass on the message to the b2bua and stop further processing of the message.

2. New routes or instruction blocks should be defined possibily in a separate conf file.

on_incoming_call[route_number] {

1. do B2BUA actions

    b2b_arm_timer( tick );
    b2b_initiate_outcall( uri );

}

• on_call_hold[route_number]
• on_call_transfer[route_number]
• on_outcall_failure[route_number]
• on_outcall_redirect[route_number]
• on_call_termination[route_number]
• on_timer[route_number]

3. Inside b2bua routes,

modules functions dedicated to b2bua could be called and a way to delegate also: a call context should be defined and it should be possible to define variables that lives during the whole call duration.

for multi party calls, provision should be made to enable one context to influence another context for instance by sending events .

B2BUA should be able to enable the implementation of the following

• limit the number of calls per user
• limit the duration of call (e.g. prepaid calls)
• handle redirect and call transfer locally
• implement simple ACD logic
• provide a server side busy / in use / free / unavailable status per user
• possibily facilitate the devlopment of protocol translators (e.g. SIP <-> H.323 ).
• ideally a mechanism such as memcached should be used to enable an active / active cluster of b2bua to sit on two different hosts.

Just dreaming.

4. New proxy routes should be define

outgoing_route[route_number]

that would process messages issued by b2bua

a b2bua_reply() function would be available in case the proxy logic chose to direcly reply to the b2bua logic