| Overview |  |
state() = #state{}
no description
| get_node/2 | find node with Index in Graph Note : Graph could be implemented as a gb_tree (see gb_tree module) which will be faster for large graphs, O(log N * log N) instead of O(N log N) (number of nodes processed = log N = path through graph). |
| get_start_node/1 | |
| process_cpl_script/4 | This is just a simpler version of process_cpl_script/7, which adopts the server transaction handler for Request, figures out the BranchBase for you and take care of some general result actions. |
| process_cpl_script/7 | execute the the cpl script and return a {Action, ....} tuple to specify what to do with the request, the Action parameter indicates the action to do There are a number of possible return values of the format {ExitType, ....}: {redirect, Permanent, Locations} * a redirect cpl tag was processed, Permanent determines if this redirection should be made permanent. |
get_node(R::Graph, Index) -> term()
throws {error, index_not_found}
find node with Index in Graph Note : Graph could be implemented as a gb_tree (see gb_tree module) which will be faster for large graphs, O(log N * log N) instead of O(N log N) (number of nodes processed = log N = path through graph)
get_start_node() -> term()
process_cpl_script(Request, User, Graph, Direction) -> {server_default_action} | {proxy_call_to_location, Location} | {proxy_or_redirect_to_locations, Locations} | ok | {error, Reason}
throws {error, atom()}
This is just a simpler version of process_cpl_script/7, which adopts the server transaction handler for Request, figures out the BranchBase for you and take care of some general result actions. See documentation of the big process_cpl_script/7 for more information.
process_cpl_script(BranchBase, Request, User, Graph, Backend, STHandler, Direction) -> {ExitType, Param} | {ExitType, Param1, Param2}
throws {error, Reason}
execute the the cpl script and return a {Action, ....} tuple to specify what to do with the request, the Action parameter indicates the action to do There are a number of possible return values of the format {ExitType, ....}: {redirect, Permanent, Locations} * a redirect cpl tag was processed, Permanent determines if this redirection should be made permanent. Locations lists the locations to redirect to, see RFC 3380 chapter 6.2 {reject, Status, Reason} {reject, Status} * a reject cpl tag was processed, see RFC 3880 chapter 6.3, Status is a numerical error code, Reason is a textual description - both are supplied by the cpl script. Reason is only supplied if the reason sub tag in the reject cpl tag is not = "" {server_default_action} * process request the same way as it would be processed if no cpl script was run, see RFC 3880 chapter 10 {proxy_call_to_location, Location} * outgoing call, cpl call supplied no additional locations or signaling operations - see RFC 3880 chapter 10 {proxy_or_redirect_to_locations, Locations} * locations where accumulated with cpl script but no signaling operation where executed, so server decides what is to be done, see RFC 3880 chapter 10 {proxy, Response} * proxy tag was processed as the last cpl action, Response contains the results from this action [1] {use_last_proxy_result, Response} * proxy tag was the last signaling action, but additional cpl tags where processed before terminating [1] throw({error, ...}) Status = integer() Response = see #state.response Permanent = yes | no Locations = list() of sipurl record() Location = sipurl record() Reason = string() RejectAttrs = reject__attr record() [1] : a {proxy ...} return is unusual in that it indicates that a proxying action has already been done - so there is no need to act on the proxy return value, as is needed for the other return values. Note : CPL processing should be done in a spawned process - cpl processing can take a long time (waiting for timeouts) and many scripts may needed to be run at the same time
Generated by EDoc, Oct 17 2007, 16:48:06.