Sophie

Sophie

distrib > Fedora > 15 > i386 > by-pkgid > 29302705d596409cad7ef2bf7486064a > files > 5

opensips-b2bua-1.6.4-6.fc15.i686.rpm

B2B_LOGIC

Anca-Maria Vamanu

   OpenSIPS

Edited by

Anca-Maria Vamanu

   Copyright © 2009 Anca-Maria
   Vamanu
   Revision History
   Revision $Revision: $ $Date: $
     __________________________________________________________

   Table of Contents

   1. Admin Guide

        1.1. Overview
        1.2. Dependencies

              1.2.1. OpenSIPS Modules
              1.2.2. External Libraries or Applications

        1.3. Exported Parameters

              1.3.1. hash_size (int)
              1.3.2. script_scenario (str)
              1.3.3. extern_scenario (str)
              1.3.4. cleanup_period (int)
              1.3.5. custom_headers (str)
              1.3.6. use_init_sdp (int)

        1.4. Exported Functions

              1.4.1. b2b_init_request

        1.5. Exported MI Functions

              1.5.1. b2b_trigger_scenario
              1.5.2. b2b_bridge

   List of Examples

   1.1. Set server_hsize parameter
   1.2. Set script_scenario parameter
   1.3. Set script_scenario parameter
   1.4. Set cleanup_period parameter
   1.5. Set parameter
   1.6. Set parameter
   1.7. b2b_init_request usage

Chapter 1. Admin Guide

1.1. Overview

   The B2BUA implementation in OpenSIPS is separated in two
   layers:
     * a lower one(coded in b2b_entities module)- which implements
       the basic functions of a UAS and UAC
     * an upper one - which represents the logic engine of B2BUA,
       responsible of actually implementing the B2BUA services
       using the functions offered by the low level.

   This module is a B2BUA upper level implementation that can be
   used with b2b_entities module to have B2BUA that can be
   configured to provide some PBX services. The B2B services are
   coded in an XML scenario document. The b2b_logic module
   examines this document and uses the functions provided by the
   b2b_entities module to achieve the actions specified in the
   document and enable the service.

   A scenario can be instantiated in two ways:
     * from the script - at the receipt of a initial message
     * with a extern command (MI) command - the server will
       connect two end points in a session(Third Party Call
       Control).

1.2. Dependencies

1.2.1. OpenSIPS Modules

     * none

1.2.2. External Libraries or Applications

   The following libraries or applications must be installed
   before running OpenSIPS with this module loaded:
     * libxml2-dev

1.3. Exported Parameters

1.3.1. hash_size (int)

   The size of the hash table that stores the scenario
   instatiation entities.

   Default value is “9” (512 records).

   Example 1.1. Set server_hsize parameter
...
modparam("b2b_logic", "hash_size", 10)
...

1.3.2. script_scenario (str)

   This parameter should be set with the path of a document that
   contains a scenario that can be instantiated from the script at
   the receipt of an initial message.

   This parameter can be set more than once.

   Example 1.2. Set script_scenario parameter
...
modparam("b2b_logic", "script_scenario", "/usr/local/opensips/scripts/b2
b_prepaid.xml")
...

1.3.3. extern_scenario (str)

   This parameter should be set with the path of a document that
   contains a scenario that can be instantiated with an MI
   command.

   This parameter can be set more than once.

   Example 1.3. Set script_scenario parameter
...
modparam("b2b_logic", "extern_scenario", "/usr/local/opensips/scripts/b2
b_marketing.xml")
...

1.3.4. cleanup_period (int)

   The time interval at which to search for an hanged b2b context.
   A scenario is considered expired if the duration of a session
   exceeds the lifetime specified in the scenario. At that moment,
   BYE is sent in all the dialogs from that context and the
   context is deleted.

   Default value is “100”.

   Example 1.4. Set cleanup_period parameter
...
modparam("b2b_logic", "cleanup_period", 60)
...

1.3.5. custom_headers (str)

   A list of SIP header names delimited by ';' that should be
   passed from the dialog of one side to the other side. There are
   a number of headers that are passed by default. They are:
     * Max-Forwards (it is decreased by 1)
     * Content-Type
     * Supported
     * Allow
     * Proxy-Require
     * Session-Expires
     * Min-SE
     * Require
     * RSeq

   If you wish some other headers to be passed also you should
   define them by setting this parameter.

   Default value is “NULL”.

   Example 1.5. Set parameter
...
modparam("b2b_logic", "custom_headers", "User-Agent;Date")
...

1.3.6. use_init_sdp (int)

   This parameter modifies the behaviour of the B2BUA when
   bridging and a provisional media uri is set. For playing media
   while the callee answers (that is connecting the caller to a
   media server), the bridging with the callee must start by
   sending an Invite to it. The correct way is to send an Invite
   without a body in this case, but it has been observed that not
   many gateways support this. So, the solution is to use the sdp
   received in the first Invite from the caller and put it as the
   body for this invite. By setting this parameter, this behavior
   is enabled.

   Default value is “0”.

   Example 1.6. Set parameter
...
modparam("b2b_logic", "use_init_sdp", 1)
...

1.4. Exported Functions

1.4.1.  b2b_init_request

   This is the function that must be called by the script writer
   on an initial INVITE for which a B2B scenario must be
   instantiated. It is up to the script writer to decide which are
   the criteria to decide for which messages certain scenarios
   must be instantiated.

   The first parameter is the identifier for the scenario. This is
   defined in the XML document as an attribute of the root node.

   Then it can take at most 4 other parameters that represent the
   parameters for the xml scenario. The expected number of
   parameters is also specified as an attribute in the root node
   of the XML scenario.

   NOTE: Do not call t_newtran() from the script on this request.
   It will be called internally by the function. Calling
   t_newtran() from the script will result in the transaction
   remaining in memory for ever.

   Example 1.7. b2b_init_request usage
...
if(is_method("INVITE") && !has_totag() && prepaid_user())
   b2b_init_request("prepaid", "sip:320@opensips.org:5070",
      "sip:321@opensips.org:5070"));
...

1.5. Exported MI Functions

1.5.1.  b2b_trigger_scenario

   This command instantiated a B2B scenario.

   Name: b2b_trigger_scenario

   Parameters:
     * senario_id : the id of the scenario to be instantiated.
     * scenario parameters - it can take 4 more parameters that
       are scenario parameters

   MI FIFO Command Format:
        :b2b_trigger_scenario:fifo_reply
        marketing
        sip:bob@opensips.org
        sip:322@opensips.org:5070
        sip:alice@opensips.org
        _empty_line_

1.5.2.  b2b_bridge

   This command can be used by an external application to tell
   B2BUA to bridge a call party from an on going dialog to another
   destination. By default the caller is bridged to the new uri
   and BYE is set to the callee. You can instead bridge the callee
   if you send 1 as the third parameter.

   Name: b2b_trigger_scenario

   Parameters:
     * dialog-id : the id of the dialog. If you set the module
       parameter dialog-id the server will include the dialogid in
       the generated Invites as the content of a header with name
       'Dialog-ID'.
     * new uri - the uri of the new destination
     * flag to specify that the callee must be bridged to the new
       destination. It is optional. If not present the caller will
       be bridged.

   MI FIFO Command Format:
                opensipsctl fifo b2b_bridge 1020.30 sip:alice@opensips.o
rg