openSIPS | Resources / B2buaTutorial

April 24, 2013, at 06:52 PM by 109.99.235.212 -

Changed lines 1-361 from:

!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsTutorials | Tutorials]]-> B2BUA
----

!Back-to-Back User Agent
%block text-align=right% '''written by Anca Vamanu'''

(:toc Table of Content:)

[[#Overview]]
!! Overview

OpenSIPS has many features but in the way it behaves when a media session is established, it is not more than a proxy, meaning that it only takes the messages from one side and pass them on the other side. However, this has proven not to be enough as to provide certain services it is required for the server to be aware of the state of the sessions, monitor and control them. A Back-to-Back User Agent is exactly this, a entity in the SIP network which has the ability to control or start media sessions. The name comes from the behavior, since in fact what is required is for the B2BUA to stand in the middle and establish two dialogs with both end points that will eventually exchange media.

B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers the possibility to build certain services on top of it. It consists of two modules:
* b2b_entities - the bottom half, implementing the behavior of UAC and UAS (B2BUA)
* b2b_logic - the upper half, implementing a logic for analyzing and applying services scenarios to achieve the desired B2BUA specific services.

The picture bellow shows the architecture of the B2BUA implementation.

http://www.opensips.org/images/B2BUA_architecture.jpg

The reason for which the architecture has two parts is to allow extensions and integration with other system that might implement their own logic interpretor. Instead of the b2b_logic module, another module with a different logic interpretor or scenario source can be placed there and use the interface that the b2b_entities module offers to build quickly a new B2BUA implementation. The b2b_entities role in the processing is an independent one that is required in any B2B implementation and it is therefore encoded in a separate module. It offer an upper level library that will make the implementation of another logic interpreter and applier much easier. The separation enhances and encourages extension and integration with other systems.

The two parts composing B2BUA in OpenSIPS are bound to each other in a control-notify relationship. The b2b_logic module controls the b2b_entities by sending commands and telling it what messages to send and the b2b_entities modules notifies the b2b_logic module when a request or a reply is received for a dialog that the B2B is handling.

!!!Server Entity and Client Entity
The name represents in fact the type if transaction entity that is created at the beginning. So there will be a
* b2b server entity if it is created when a message is received and has to reply to it
* b2b client entity if the entity will have to start a dialog by sending an initial message

!!!Scenario Instantiation
The services are defined in documents called scenarios. A scenario instantiation is an application of a scenario that is currently in progress. The b2b_logic module might be told to initialize a scenario in two ways: from the script, by calling a function that the module exports when an initial request is received, or by sending an external command. When receiving one of this two events, the b2b_logic module will create a record(corresponding to the red small boxes in the drawing) with the information for that scenario instantiation. Also at this moment, the b2b_logic module tells the b2b_entities module to create the entities(server and/or clients) that it requires. The record mainly stores a relation to the scenario document that it must follow, the state of the scenario application and the identifiers for the entities in b2b_entities module.

!!!Communication with the exterior
As can be seen in the picture, the b2b_entities module is the bottom half part of B2BUA and it deals with the actual network message exchange. To achieve this it uses directly the functions provided by the '''tm''' module for sending requests and replies and for receiving replies. Also the tm module announce it when a reply for a request that it has sent is received. For requests inside dialog, the b2b_entities module registers a prescript function that catches this requests. In the current implementation, this requests don't go into the script because the prescript function returns '0'. As mentioned earlier, when receiving a reply or request that is matched to a known dialog, the b2b_entities module does no further action but notifies the b2b_logic module about this event. The b2b_logic module which is the upper half, will then decide what actions should be taken and sends back control commands to the b2b_entities module.

[[#Initiating_B2B_services]]
!! Initiating B2B services

There are two ways to trigger a B2B service.
* from script
* with an MI command

The function that can be called from the script has the name '''b2b_init_request''' and has 6 parameters:

'''b2b_init_request''' ( scenario_name, param1, param2, param3, param4, param5)

%color=#ff7f00% NOTE: This function has to be called on the initial Invite only ( the B2BUA must be in the middle of the call from the beginning). %black%

The first parameter is the name of the scenario to be instantiated. So it is the job of the script writer to decide when a certain scenario should be applied . The next arguments are parameters needed by the scenario. As it shall be seen later, a scenario can require some values to be given as parameters in contrast to hard coding them, making the scenario configurable.

The MI command has the name '''b2b_trigger_scenario''' and takes exactly the same parameters as the script function.

%color=#ff7f00% Ex: %black%'''Fifo MI command'''
>>lframe black<<
:b2b_trigger_scenario[=:=]fifo_reply[[<<]]
marketing[[<<]]
sip:bob@opensips.org[[<<]]
sip:322@opensips.org:5070[[<<]]
sip:alice@opensips.org
_empty_line_
>><<

[[<<]]
[[<<]]
There is one predefined service that works without any scenario definition and for any type of dialog. This is '''topology hiding''' service. The functionality is obvious from the name and what this service does is to hide the network topology from the parties that establish a dialog. To achieve this, the B2BUA poses itself in the middle and established dialogs with both parties. Then all it will do next will be to translate a receipt request or reply into the dialog from the other side and forward it to the peer entity.

This service can only be selected from the script, because it has sense only when a dialog is initiated. It does not require any parameter. The id for this scenario is '''top hiding'''.

%color=#ff7f00% Ex:%black% '''Calling top hiding service'''
>>lframe<<
<pre>if(is_method("INVITE") && src_ip=="10.10.10.10")    b2b_init_request("top hiding");</pre>
>><<
[[<<]]
Other services must be defined in scenario documents and loaded at startup by providing the path towards them as module parameters as presented in the following chapter.

[[#Loading_scenarios]]
!! Loading scenarios

The scenario documents are loaded at startup and their paths in the system must be provided through module parameters that belong to the b2b_logic module. There are two parameters, one of each type of scenario: '''scenario_script''' and '''scenario_extern'''.

%color=#ff7f00% Ex:%black% '''Loading B2BUA scenarios'''
>>lframe<<
<pre>modparam("b2b_logic", "script_scenario", "/usr/local/opensips/etc/b2bua/scenario_script.xml") modparam("b2b_logic", "extern_scenario", "/usr/local/opensips/etc/b2bua/scenario_extern.xml")</pre>
>><<
[[<<]]

[[#B2BUA_scenario_format]]
!! Scenario format
The scenarios are defined as XML documents because of their adaptability and because they are easy to understand and write.

A scenario is a predefined behavior that will be interpreted by the B2B Logic. The decision when the the scenario will be applied must be taken by the server administrator in the configuration file or triggered by an extern application with an MI command.

The scenario is not rigid, but configurable through some parameters that will have to be provided to the B2B logic when requesting the instantiation of a certain scenario.

!!! Scenario root
The '''root''' element has the tag 'scenario'.
[[<<]]
%color=#ff7f00% Ex: %black%'''Scenario root node example'''
>>lframe<<
<pre><scenario id="prepaid" name="MS start and end" param="2" type="script"></pre>
>><<
[[<<]]

It has three parameters:

* '''id �''' the identifier for the scenario. It will be provided to the logic when desiring to instantiate the scenario.
* '''name''' � a more explicit name. It has meaning only for the reader, with no importance for the B2BUA.
* '''param''' � the number of parameters the scenario requires.
* '''type''' � the type of the scenario. It can be ''script'' or ''extern.'' This parameter as the name parameter is not meaningful to the B2BUA but to the reader.

A B2B scenario document has two parts:

* a '''init''' section
* a '''rules''' section

!!! Init section
The '''init''' section provides indications about the entities that must be created at the beginning of the scenario. The '''init''' node has as a subnode a '''bridging''' node meaning that the entities created there will eventually be connected in a media session.

There can be two types of entities:

* '''server entity''' � for the first transaction the entity will behave as a UAS. This can be created only if there is a INVITE message that the entity will have to deal with. Server entities can appear only in scrip scenarios.
* '''client entity''' - a entity that has to start a dialog and send an initial message to a SIP endpoint.

Some parameters must be defined for the entities. Both server and client entities must be given an '''id''' that will be used to identify the entity later in the script. For the server entity no other parameters need to be defined.

For the client entities it is compulsory to define the destination where the messages will be sent. For this a '''destination''' sub node must be defined. The syntax of the destination node is:

The destination value can be provided in more ways
[[<<]]
%color=#ff7f00% Ex: %black%'''Scenario destination node example'''
>>lframe<<
<pre><destination>    <value type="_value_type_">_value_</value> </destination></pre>
>><<
[[<<]]
[[<<]]
%color=#ff7f00% Table: %black%'''Scenario destination node structure'''
|| border=1
||Value source||Value type||Example||
||Inline URI ||"uri" ||<pre><destination>    <value type="uri">sip:ms@opensips.org</value> </destination></pre>||
||Parameter.The value node content is a number and represents the number of the parameter.||"param"||<pre><destination>    <value type="param">1</value> </destination></pre>||
||Initial destination.Used when the bridging is based on a received message. The destination will be that from the message.||"initial"||<pre><destination>    <value type="initial"></value> </destination></pre>||
||Header body.Take the URI from the body of a header. The first header with that name will be used. ||"header" || <pre><destination>    <value type="header">Refer-To</value> </destination></pre>||

The client entity can also have a '''type''' subnode. The only defined value for this node is ''''message''''. If type node with message value is present, it means that the client will be created using the info from received SIP message: the body, the caller URI, some SIP headers(Accept, Supported, Content-Type). Defining this node does not mean that the destination will be taken from this message and still a destination node must be defined.

In addition to the bridging node, you can also define a state node. The meaning of states in the b2b scenario is that of labels in the evolution of the scenario that can be used as conditions when defining rules. A '''state '''node in the '''init''' node specifies the state that the scenario instantiation will enter after the init part will be executed.

Below there are two examples of scenario init parts, one that creates entities based on a received message and in
which the dialog is initiated by the b2bua that puts two entities in contact.

[[<<]]
%color=#ff7f00% Table: %black%'''Scenario init node examples'''
||border=1
||'''Script scenario'''||'''Extern Scenario'''||
||<pre><init>    <bridge>       <server>          <id>server1</id>       </server>       <client>          <id>client1</id>          <type>message</type>          <destination>             <value type="param">1</value>          </destination>       </client>       <lifetime>120</lifetime>    </bridge>    <state>1</state> </init> </pre>||<pre><init>      <bridge>           <client>                <id>client1</id>                <destination>                     <value type="param">1</value>                </destination>           </client>                     <client>                <id>client2</id>                <destination>                     <value type="param">2</value>                </destination>           </client>           <lifetime>300</lifetime>      </bridge>        <state>1</state> </init></pre>||

!!! Rules section
The rules have two parts:

* condition
* action

The condition part decides whether a rule should be applied for the current event. The events are represented by the receipt of a SIP request or SIP reply. The action part may define a request or reply to be sent out.

In the scenario document, the rules node has two children, requests and replies, separating the two types of events. Then both replies and requests have children with names of the possible requests inside dialog: 'invite', 'ack', 'bye' and for each more rules can be defined.

%color=#ff7f00% Ex: %black%'''Scenario rules node structure'''
[[<<]]
>>lframe<<
<pre><rules>   <request>     <bye>       <rule id= �1�>         ...       </rule>       <rule id= �2�>         ...       </rule>     </bye>   </request> </rules> </pre>
>><<
[[<<]]

!!!! Rules condition part
The extra conditions that can be defined for a rule filter the scenario state and the direction of the message.

A condition will be matched if the scenario instantiation is in the same state as the state specified in the condition.

The direction of a message is specified with a '''sender''' node. The sender can be a certain entity specified with a type and an id, or a entity category, being sufficient to specify only the type.

[[<<]]
%color=#ff7f00% Ex: %black%'''Scenario condition node'''
>>lframe<<
<pre><condition>    <state>1</state>    <sender>       <type>client</type>       <id>client1</id>    </sender> </condition></pre>
>><<
[[<<]]

!!!! Rules action part
In this first version there are four possible actions, with the possibility to extend them in the future. The actions are described in the table bellow.

[[<<]]
%color=#ff7f00% Table: %black%'''Scenario rules node structure'''

||border=1
||'''Node name'''||'''Description'''||'''Example'''||
||send_reply||This node tells the B2BUA to send a reply to the sender of the current message. A code and reason sub node must be defined.||<pre><send_reply>   <code>200</code>   <reason>OK</reason> </send_reply></pre>||
||delete_entity||The delete_entity node specifies to the B2B Logic that the current entity which has received the message can be deleted.||<pre><delete_entity/></pre>||
||bridge||A bridge action means putting two end points in contact. The syntax is the same as the one for the bridge node in the init part. The only difference here is that the entities can be also existing ones. To refer to an existing entity, you must use the same "id". If a new entity has to be created, a '''<destination>''' node must be present. To force the creation of a new entity, insert a '''<new/>''' subnode for the client. The client node also allows a '''<lifetime>''' subnode. It defines the maximum duration of the media session and it is used to track blocked scenario instantiations. If the lifetime expires, the B2BUA will send BYE messages to both ends and delete the record. This parameter is not compulsory and should be defined when a maximum lifetime value is known(most likely in the case of recorded messages played by media servers).||<pre><bridge>  <client>    <id>client1</id>  </client>  <client>    <id>client3</id>    <destination>      <value type="param">      3</value>  </destination>  </client>  <lifetime>79800</lifetime> </bridge></pre>||
||state||Specifies the state the scenario instantiation will enter after the action will be executed.||<pre><state>2</state></pre>||
||end_dialog_leg||This node tells the B2BUA to end the call that has just received an event ( request or reply). The B2BUA will send a BYE request to the party.||<pre><end_dialog_leg/></pre>||

Bellow is an action example:
[[<<]]
%color=#ff7f00% Ex: %black%'''Scenario action node'''
>>lframe<<
<pre><action>     <send_reply>       <code>200</code>       <reason>OK</reason>     </send_reply>     <delete_entity/>     <bridge>       <client>         <id>server1</id>       </client>       <client>         <id>client2</id>         <destination>           <value type="initial">server1</value>         </destination>       </client>     </bridge>     <state>2</state> </action></pre>
>><<
[[<<]]

[[#Scenario_examples]]
!! Scenario Examples
!!! Topology Hiding
No scenario document must be defined for this usage case. This is a built in mechanism and it
can be requested to the B2B Logic by specifying the name "top hiding".
The functionality is a simple pass through with the creation of a new dialog on the other side
and transferring all the messages received on one side to the other side taking care only to
change the dialog information.

!!!!Scenario Schema
Here is the theoretical expected message trace:

http://www.opensips.org/images/top_hiding_schema.jpeg

!!! Prepaid
This scenario can be used by a company for prepaid users to announce them at the beginning of the call what their credit is and at the end of the call what their remaining credit is.

What must happen at session level is:

# the caller is connected to a media server
# the caller is connected to the callee
# if the callee hangs up the phone before the caller, the caller is connected to a media server (the same or other).

In B2BUA terms, this is a script scenario that can be instantiating by specifying the id '''prepaid'''. It requires 2 parameters:
* the location of the first media server
* the location of the second media server

!!!! Scenario Schema
To establish this sessions the SIP message flow has to look like this( it is assumed that the
same media server is used):

http://www.opensips.org/images/ppaid.jpeg

!!!! Scenario Document
The full scenario document is printed bellow:
>>lframe<<
<pre><?xml version="1.0"?> <scenario id="prepaid" name="MS start and end" param="2" type="script">      <init>          <bridge>             <server>                 <id>server1</id>             </server>             <client>                 <id>client1</id>                 <type>message</type>                 <destination>                     <value type="param">1</value>                 </destination>             </client>          </bridge>     <state>1</state>      </init>      <rules>          <request>              <bye>                  <rule id="1">                      <condition>                          <state>1</state>                          <sender>                              <type>client</type>                              <id>client1</id>                          </sender>                      </condition>                      <action>                          <send_reply>                              <code>200</code>                              <reason>OK</reason>                          </send_reply>                          <delete_entity/>                          <bridge>                              <client>                                  <id>server1</id>                              </client>                              <client>                                  <id>client2</id>                                  <destination>                                      <value type="initial">server1</value>                                  </destination>                              </client>                          </bridge>                          <state>2</state>                      </action>                  </rule>                  <rule id="2">                     <condition>                         <state>2</state>                         <sender>                             <type>client</type>                             <id>client2</id>                         </sender>                     </condition>                     <action>                         <send_reply>                             <code>200</code>                              <reason>OK</reason>                         </send_reply>                          <delete_entity/>                          <bridge>                              <client>                                  <id>server1</id>                              </client>                               <client>                                   <id>client3</id>                                   <destination>                                       <value type="param">2</value>                                   </destination>                               </client>                          </bridge>                          <state>3</state>                      </action>                  </rule>             </bye>         </request>     </rules> </scenario> </pre>
>><<
[[<<]]

!!! Marketing
The last test case is called �Marketing�, because it suits very well to the requirements of a marketing campaign through phone. The company might choose a list of potential costumers to call and announce about a new product/offer/discount. The message will be a recorded one, but the costumer will also be offered the possibility to talk to a human operator. If the costumer does not hung up the phone before the recorded message ends, it will be connected to a human operator. This is also a good means to filter the interested costumers and make the process more efficient with less resources used.

The OpenSIPS B2BUA must connect two end points, start the call from the middle. It is different from the other examples, since the call is initiated by the B2BUA and it is triggered by a MI command.

The id which must be mentioned to start this service is 'marketing'. It requires 3 parameters
* the URI of the possible costumer
* the URI of the media server
* the URI of the human operator

!!!! Scenario Schema
Below is the theoretical message flow that should occur for this functionality to be achieved.

http://www.opensips.org/images/marketing.jpeg

!!!! Scenario Document
The scenario document that describes this service is:
>>lframe<<
<pre><?xml version="1.0"?> <scenario id="marketing" name="MS start conditional" param="3" type="extern">   <init>     <bridge>     <client>         <id>client1</id>         <destination>            <value type="param">1</value>         </destination>     </client>     <client>         <id>client2</id>         <destination>            <value type="param">2</value>         </destination>     </client>     </bridge>     <state>1</state>   </init>   <rules>     <request>        <bye>           <rule id="1">              <condition>                 <state>1</state>                 <sender>                    <type>client</type>                    <id>client2</id>                 </sender>              </condition>              <action>              <send_reply>                 <code>200</code>                 <reason>OK</reason>              </send_reply>              <delete_entity/>              <bridge>                 <client>                    <id>client1</id>                 </client>                 <client>                    <id>client3</id>                    <destination>                       <value type="param">3</value>                    </destination>                 </client>              </bridge>              <state>2</state>              </action>              </rule>          </bye>       </request>    </rules> </scenario></pre>
>><<
[[<<]]

!!! REFER Scenario

The B2BUA component can also be configured to handle blind transfers(with REFER SIP message). This is useful when in the platform there are devices that do not accept the REFER method. The scenario for this case is very simple and has one rule for when a REFER is received. This rule tells the B2BUA to end the call with the user agent that sent the refer message and to bridge the peer with the user specified in the 'Refer-To' header.

!!!! Scenario Document
The scenario document that describes this service is:
>>lframe<<
<pre><?xml version="1.0"?> <scenario id="refer" name="Handle refer at server" param="0" type="script">   <init>     <bridge>       <server>         <id>server1</id>       </server>       <client>         <id>client1</id>         <type>message</type>         <destination>           <value type="initial">server1</value>         </destination>       </client>     </bridge>   </init>   <rules>      <request>        <refer>          <rule id="1">            <action>              <send_reply>                <code>202</code>                <reason>Accepted</reason>              </send_reply>              <end_dialog_leg/>              <bridge>                <client>                  <peer/>                </client>                <client>                  <id>client2</id>                  <destination>                    <value type="header">Refer-To</value>                  </destination>                </client>              </bridge>            </action>          </rule>        </refer>     </request>   </rules> </scenario></pre>
>><<
[[<<]]

[[#Configuration_file_example]]
!! Configuration file

%color=#ff7f00% You must note that, a call that is handled by the B2B will not have the normal �proxy like� interaction with the script.

Once you ask b2b to handle a call, you '''won't see the future in-dialog request in the normal route'''. The reason is that in the normal route you do proxy operations - changes on the message, routing decisions, but for the b2b calls those requests will have the b2b as an endpoint. The b2b will then generate new messages that will be sent on the other side. It will not forward the received ones. Those new generated can be accessed in local_route.

If the scenario is called from script on an initial Invite, you must take care to drop this request after calling b2b_init_request() function on it ( call 'exit', don't call t_relay() on it ).

When using b2b all the changes that you want to perform on a message must be done in local_route on the new generated request that will be sent out.

Because sometimes it is required to also access the received requests, you can define a special route '''b2b_request route''' where you can do 'read-only' operation on the request, like accounting or logging.
Also, you can define a special '''b2b_reply route''' where you can see the received replies.

As a conclusion, when a call is handled by the b2bua, SIP messages for that call will be accessible in:
* '''b2b_request route''' : the received requests. This request will not be forwarded so doing changes on the message will have no effect. This route is useful for logging and accounting.
* '''b2b_reply route''' : the received replies. The same as with the requests, it has no effect to do changes on it.
* '''local_route''' : the SIP requests that are sent out by the b2bua. Here changes on the message can be performed.

%color=#ff7f00% Also, note that '''dialog''' module does not work with B2BUA. The reason is that this module was designed to handle proxy dialogs.

!!! Writing the configuration file

There are some requirements for a configuration file that enables the B2BUA services.

* load modules '''b2b_entities''' and '''b2b_logic'''
* set module parameters
** compulsory: the '''server_address''' parameter in b2b_entities
** optional:
*** '''script_scenario''' and '''extern_scenario''' in b2b_logic for loading service scenarios
*** parameters for the hash tables - server_hsize and client_hsize in b2b_entities module and '''hash_size''' in b2b_logic module

* load a MI module if you need to support triggering B2BUA scenarios with extern commands. Depending on the transport you require, either mi_fifo or mi_xmlrpc or mi_datagram.
* built the filters and call the script scenario instantiating function

Also please note that you need to configure the tm module to pass provisional replies. For this you need to set the module parameter:

>>lframe blue<<
<pre>modparam("tm", "pass_provisional_replies", 1)</pre>
>><<
[[<<]]

!!! Example

You can find [[b2b_config_example|here]] a configuration file example that loads the two scenarios presented in this tutorial and enables the '''prepaid''' service for a certain user. Also the mi_fifo module is loaded here and it will be possible to send MI commands to instantiate the '''marketing''' scenario.

!!! Script routes
!!!! Special B2B route
The requests and replies that are received by the B2BUA server, belonging to the dialogs it is handling will not go into the script as normal request do. The reason for this is that this are not normal requests where the server is a proxy, but the server is an endpoint in the dialog and therefore they should not go through the same routes. However, it is normal for this request to be seen from the script and allow the script writer to do the processing it desires based on them. For this, it is possible to define two special B2B routes - one for requests and one for replies. The routes are of type '''route''' and have their name defined in the modules parameters '''script_req_route''' and '''script_reply_route'''.

>>lframe blue<<
<pre>modparam("b2b_entities", "script_req_route", "b2b_request") modparam("b2b_entities", "script_reply_route", "b2b_reply") route[b2b_request] {   xlog("b2b_request ($ci)\n"); } route[b2b_reply] {   xlog("b2b_reply ($ci)\n"); }</pre>
>><<
[[<<]]

!!!! Failure route not available for B2B

It is impossible to have a '''t_on_failure()''' mechanism (which is transaction specific) on a B2BUA scenario (where you have multiple dialogs, with multiple transactions) - for complex scenarios, with multiple dialogs, you cannot say for which transaction to trigger the failure route for. The "topo hiding" scenario is a very simple B2BUA scenario, but you cannot have a general "on_failure" concept for all b2bua scenarios.

A solution is to consider that b2bua is a separate instance (logically speaking) which selects types/classes of destinations. A proxy instance will responsible for routing inside the class of destinations.

For ex: in a scenario we can sent in the first place the call to Media Server for some announcement and later to PSTN GW. In a first step, the b2bua scenario will sent to proxy the call with RURI pointing to "a class"
of media servers - the proxy will select the proper media server and do the failover between the media servers, totally transparent for the b2bua. In a similar way, on the second step, the b2bua scenario will indicate to proxy that it wants to have the call to be sent to PSTN GW (as type of destination) - the proxy will do lcr, drouting, failover between the GW.

to:

(:redirect Documentation/Tutorials-B2BUA quiet=1:)

May 25, 2012, at 09:09 PM by anca_vamanu - Description of the new node.

Changed line 208 from:

||bridge||A bridge action means putting two end points in contact. The syntax is the same as the on for the bridge node in the init part. The only difference here is that the entities can be also existing ones. If a new entity is defined a destination node must be present. Note that there is also a lifetime node. It defines the maximum duration of the media session and it is used to track blocked scenario instantiations. If the lifetime expires, the B2BUA will send BYE messages to both ends and delete the record. This parameter is not compulsory and should be defined when a maximum lifetime value is known(most likely in the case of recorded messages played by media servers).||<pre><bridge>  <client>    <id>client1</id>  </client>  <client>    <id>client3</id>    <destination>      <value type="param">      3</value>  </destination>  </client>  <lifetime>79800</lifetime> </bridge></pre>||

to:

||bridge||A bridge action means putting two end points in contact. The syntax is the same as the one for the bridge node in the init part. The only difference here is that the entities can be also existing ones. To refer to an existing entity, you must use the same "id". If a new entity has to be created, a '''<destination>''' node must be present. To force the creation of a new entity, insert a '''<new/>''' subnode for the client. The client node also allows a '''<lifetime>''' subnode. It defines the maximum duration of the media session and it is used to track blocked scenario instantiations. If the lifetime expires, the B2BUA will send BYE messages to both ends and delete the record. This parameter is not compulsory and should be defined when a maximum lifetime value is known(most likely in the case of recorded messages played by media servers).||<pre><bridge>  <client>    <id>client1</id>  </client>  <client>    <id>client3</id>    <destination>      <value type="param">      3</value>  </destination>  </client>  <lifetime>79800</lifetime> </bridge></pre>||

April 27, 2011, at 01:48 PM by anca_vamanu -

Added lines 315-316:

%color=#ff7f00% Also, note that '''dialog''' module does not work with B2BUA. The reason is that this module was designed to handle proxy dialogs.

April 21, 2011, at 01:42 PM by anca_vamanu -

Deleted lines 309-315:

The pictures below show the script interaction with the b2b requests:
* Initial request
http://opensips.org/images/b2b_route_init.jpg

* Sequential request:
http://opensips.org/images/b2b_route_seq.jpg

April 21, 2011, at 01:22 PM by anca_vamanu -

Added lines 300-324:

%color=#ff7f00% You must note that, a call that is handled by the B2B will not have the normal �proxy like� interaction with the script.

Once you ask b2b to handle a call, you '''won't see the future in-dialog request in the normal route'''. The reason is that in the normal route you do proxy operations - changes on the message, routing decisions, but for the b2b calls those requests will have the b2b as an endpoint. The b2b will then generate new messages that will be sent on the other side. It will not forward the received ones. Those new generated can be accessed in local_route.

If the scenario is called from script on an initial Invite, you must take care to drop this request after calling b2b_init_request() function on it ( call 'exit', don't call t_relay() on it ).

When using b2b all the changes that you want to perform on a message must be done in local_route on the new generated request that will be sent out.

Because sometimes it is required to also access the received requests, you can define a special route '''b2b_request route''' where you can do 'read-only' operation on the request, like accounting or logging.
Also, you can define a special '''b2b_reply route''' where you can see the received replies.

The pictures below show the script interaction with the b2b requests:
* Initial request
http://opensips.org/images/b2b_route_init.jpg

* Sequential request:
http://opensips.org/images/b2b_route_seq.jpg

As a conclusion, when a call is handled by the b2bua, SIP messages for that call will be accessible in:
* '''b2b_request route''' : the received requests. This request will not be forwarded so doing changes on the message will have no effect. This route is useful for logging and accounting.
* '''b2b_reply route''' : the received replies. The same as with the requests, it has no effect to do changes on it.
* '''local_route''' : the SIP requests that are sent out by the b2bua. Here changes on the message can be performed.

!!! Writing the configuration file

Added line 343:

April 03, 2011, at 02:29 PM by anca_vamanu -

Changed line 171 from:

The condition part decides weather a rule should be applied for the current event. The events are represented by the receipt of a SIP request or SIP reply. The action part may define a request or reply to be sent out.

to:

The condition part decides whether a rule should be applied for the current event. The events are represented by the receipt of a SIP request or SIP reply. The action part may define a request or reply to be sent out.

February 11, 2011, at 03:41 PM by anca_vamanu -

Added line 5:

%block text-align=right% '''written by Anca Vamanu'''

January 03, 2011, at 03:28 PM by anca_vamanu -

Added lines 47-48:

%color=#ff7f00% NOTE: This function has to be called on the initial Invite only ( the B2BUA must be in the middle of the call from the beginning). %black%

November 06, 2009, at 02:59 PM by anca_vamanu -

Added lines 281-292:

!!! REFER Scenario

The B2BUA component can also be configured to handle blind transfers(with REFER SIP message). This is useful when in the platform there are devices that do not accept the REFER method. The scenario for this case is very simple and has one rule for when a REFER is received. This rule tells the B2BUA to end the call with the user agent that sent the refer message and to bridge the peer with the user specified in the 'Refer-To' header.

!!!! Scenario Document
The scenario document that describes this service is:
>>lframe<<
<pre><?xml version="1.0"?> <scenario id="refer" name="Handle refer at server" param="0" type="script">   <init>     <bridge>       <server>         <id>server1</id>       </server>       <client>         <id>client1</id>         <type>message</type>         <destination>           <value type="initial">server1</value>         </destination>       </client>     </bridge>   </init>   <rules>      <request>        <refer>          <rule id="1">            <action>              <send_reply>                <code>202</code>                <reason>Accepted</reason>              </send_reply>              <end_dialog_leg/>              <bridge>                <client>                  <peer/>                </client>                <client>                  <id>client2</id>                  <destination>                    <value type="header">Refer-To</value>                  </destination>                </client>              </bridge>            </action>          </rule>        </refer>     </request>   </rules> </scenario></pre>
>><<
[[<<]]

November 06, 2009, at 01:54 PM by anca_vamanu -

Added line 145:

||Header body.Take the URI from the body of a header. The first header with that name will be used. ||"header" || <pre><destination>    <value type="header">Refer-To</value> </destination></pre>||

November 06, 2009, at 01:42 PM by anca_vamanu -

Added lines 206-207:

||end_dialog_leg||This node tells the B2BUA to end the call that has just received an event ( request or reply). The B2BUA will send a BYE request to the party.||<pre><end_dialog_leg/></pre>||

October 28, 2009, at 10:44 AM by anca_vamanu -

Added lines 267-272:

!!!! Scenario Schema
Below is the theoretical message flow that should occur for this functionality to be achieved.

http://www.opensips.org/images/marketing.jpeg

!!!! Scenario Document

October 28, 2009, at 10:38 AM by anca_vamanu -

Changed lines 218-221 from:

In this section there are presented two scenario examples, one that can be triggered from the script and one for the MI command.

to:

!!! Topology Hiding
No scenario document must be defined for this usage case. This is a built in mechanism and it
can be requested to the B2B Logic by specifying the name "top hiding".
The functionality is a simple pass through with the creation of a new dialog on the other side
and transferring all the messages received on one side to the other side taking care only to
change the dialog information.

!!!!Scenario Schema
Here is the theoretical expected message trace:

http://www.opensips.org/images/top_hiding_schema.jpeg

Changed lines 243-244 from:

to:

!!!! Scenario Schema
To establish this sessions the SIP message flow has to look like this( it is assumed that the
same media server is used):

http://www.opensips.org/images/ppaid.jpeg

!!!! Scenario Document

October 27, 2009, at 10:32 AM by anca_vamanu -

Changed line 254 from:

<pre><?xml version="1.0"?> <scenary id="marketing" name="MS start conditional" param="3" type="extern">   <init>     <bridge>     <client>         <id>client1</id>         <destination>            <value type="param">1</value>         </destination>     </client>     <client>         <id>client2</id>         <destination>            <value type="param">2</value>         </destination>     </client>     </bridge>     <state>1</state>   </init>   <rules>     <request>        <bye>           <rule id="1">              <condition>                 <state>1</state>                 <sender>                    <type>client</type>                    <id>client2</id>                 </sender>              </condition>              <action>              <send_reply>                 <code>200</code>                 <reason>OK</reason>              </send_reply>              <delete_entity/>              <bridge>                 <client>                    <id>client1</id>                 </client>                 <client>                    <id>client3</id>                    <destination>                       <value type="param">3</value>                    </destination>                 </client>              </bridge>              <state>2</state>              </action>              </rule>          </bye>       </request>    </rules> </scenario></pre>

to:

<pre><?xml version="1.0"?> <scenario id="marketing" name="MS start conditional" param="3" type="extern">   <init>     <bridge>     <client>         <id>client1</id>         <destination>            <value type="param">1</value>         </destination>     </client>     <client>         <id>client2</id>         <destination>            <value type="param">2</value>         </destination>     </client>     </bridge>     <state>1</state>   </init>   <rules>     <request>        <bye>           <rule id="1">              <condition>                 <state>1</state>                 <sender>                    <type>client</type>                    <id>client2</id>                 </sender>              </condition>              <action>              <send_reply>                 <code>200</code>                 <reason>OK</reason>              </send_reply>              <delete_entity/>              <bridge>                 <client>                    <id>client1</id>                 </client>                 <client>                    <id>client3</id>                    <destination>                       <value type="param">3</value>                    </destination>                 </client>              </bridge>              <state>2</state>              </action>              </rule>          </bye>       </request>    </rules> </scenario></pre>

September 25, 2009, at 01:14 PM by anca_vamanu -

Added lines 287-292:

>>lframe blue<<
<pre>modparam("b2b_entities", "script_req_route", "b2b_request") modparam("b2b_entities", "script_reply_route", "b2b_reply") route[b2b_request] {   xlog("b2b_request ($ci)\n"); } route[b2b_reply] {   xlog("b2b_reply ($ci)\n"); }</pre>
>><<
[[<<]]

September 25, 2009, at 01:10 PM by anca_vamanu -

Changed lines 290-292 from:

It is impossible to have a '''t_on_failure()''' mechanism (which is transaction specific) on a B2BUA scenario (where you have multiple dialogs, with multiple transactions) - for complex scenarios, with multiple dialogs, you cannot say for which transaction to trigger the failure route for.....the "topo hiding" scenario is a very simple B2BUA scenario, but you cannot have a general "on_failure" concept for all b2bua scenarios.

How I see this solved, is very simple: consider that b2bua is a separate instance (logically speaking) which selects types/classes of destinations. A proxy instance will responsible for routing inside the class of destinations.

to:

It is impossible to have a '''t_on_failure()''' mechanism (which is transaction specific) on a B2BUA scenario (where you have multiple dialogs, with multiple transactions) - for complex scenarios, with multiple dialogs, you cannot say for which transaction to trigger the failure route for. The "topo hiding" scenario is a very simple B2BUA scenario, but you cannot have a general "on_failure" concept for all b2bua scenarios.

A solution is to consider that b2bua is a separate instance (logically speaking) which selects types/classes of destinations. A proxy instance will responsible for routing inside the class of destinations.

September 25, 2009, at 01:08 PM by anca_vamanu -

Changed lines 259-260 from:

!! Configuration file example

to:

!! Configuration file

Changed lines 280-295 from:

You can find [[b2b_config_example|here]] a configuration file example that loads the two scenarios presented in this tutorial and enables the '''prepaid''' service for a certain user. Also the mi_fifo module is loaded here and it will be possible to send MI commands to instantiate the '''marketing''' scenario.

to:

!!! Example

You can find [[b2b_config_example|here]] a configuration file example that loads the two scenarios presented in this tutorial and enables the '''prepaid''' service for a certain user. Also the mi_fifo module is loaded here and it will be possible to send MI commands to instantiate the '''marketing''' scenario.

!!! Script routes
!!!! Special B2B route
The requests and replies that are received by the B2BUA server, belonging to the dialogs it is handling will not go into the script as normal request do. The reason for this is that this are not normal requests where the server is a proxy, but the server is an endpoint in the dialog and therefore they should not go through the same routes. However, it is normal for this request to be seen from the script and allow the script writer to do the processing it desires based on them. For this, it is possible to define two special B2B routes - one for requests and one for replies. The routes are of type '''route''' and have their name defined in the modules parameters '''script_req_route''' and '''script_reply_route'''.

!!!! Failure route not available for B2B

It is impossible to have a '''t_on_failure()''' mechanism (which is transaction specific) on a B2BUA scenario (where you have multiple dialogs, with multiple transactions) - for complex scenarios, with multiple dialogs, you cannot say for which transaction to trigger the failure route for.....the "topo hiding" scenario is a very simple B2BUA scenario, but you cannot have a general "on_failure" concept for all b2bua scenarios.

How I see this solved, is very simple: consider that b2bua is a separate instance (logically speaking) which selects types/classes of destinations. A proxy instance will responsible for routing inside the class of destinations.

For ex: in a scenario we can sent in the first place the call to Media Server for some announcement and later to PSTN GW. In a first step, the b2bua scenario will sent to proxy the call with RURI pointing to "a class"
of media servers - the proxy will select the proper media server and do the failover between the media servers, totally transparent for the b2bua. In a similar way, on the second step, the b2bua scenario will indicate to proxy that it wants to have the call to be sent to PSTN GW (as type of destination) - the proxy will do lcr, drouting, failover between the GW.

July 31, 2009, at 12:08 PM by anca_vamanu -

Changed lines 158-160 from:

||<pre><init>    <bridge>       <server>          <id>server1</id>       </server>       <client>          <id>client1</id>          <type>message</type>          <destination>             <value type="param">1</value>          </destination>       </client>    </bridge>    <state>1</state> </init> </pre>||<pre><init>      <bridge>           <client>                <id>client1</id>                <destination>                     <value type="param">1</value>                </destination>           </client>                     <client>                <id>client2</id>                <destination>                     <value type="param">2</value>                </destination>           </client>      </bridge>        <state>1</state> </init></pre>||

to:

||<pre><init>    <bridge>       <server>          <id>server1</id>       </server>       <client>          <id>client1</id>          <type>message</type>          <destination>             <value type="param">1</value>          </destination>       </client>       <lifetime>120</lifetime>    </bridge>    <state>1</state> </init> </pre>||<pre><init>      <bridge>           <client>                <id>client1</id>                <destination>                     <value type="param">1</value>                </destination>           </client>                     <client>                <id>client2</id>                <destination>                     <value type="param">2</value>                </destination>           </client>           <lifetime>300</lifetime>      </bridge>        <state>1</state> </init></pre>||

Changed line 204 from:

||bridge||A bridge action means putting two end points in contact. The syntax is the same as the on for the bridge node in the init part. The only difference here is that the entities can be also existing ones. If a new entity is defined a destination node must be present.||<pre><bridge>  <client>    <id>client1</id>  </client>  <client>    <id>client3</id>    <destination>      <value type="param">      3</value>  </destination>  </client> </bridge></pre>||

to:

||bridge||A bridge action means putting two end points in contact. The syntax is the same as the on for the bridge node in the init part. The only difference here is that the entities can be also existing ones. If a new entity is defined a destination node must be present. Note that there is also a lifetime node. It defines the maximum duration of the media session and it is used to track blocked scenario instantiations. If the lifetime expires, the B2BUA will send BYE messages to both ends and delete the record. This parameter is not compulsory and should be defined when a maximum lifetime value is known(most likely in the case of recorded messages played by media servers).||<pre><bridge>  <client>    <id>client1</id>  </client>  <client>    <id>client3</id>    <destination>      <value type="param">      3</value>  </destination>  </client>  <lifetime>79800</lifetime> </bridge></pre>||

July 31, 2009, at 11:39 AM by anca_vamanu -

Deleted lines 6-13:

# [[Resources.B2buaTutorial:#Overview| Overview]]
# [[Resources.B2buaTutorial:#Initiating_B2B_services| Initiating B2B services]]
# [[Resources.B2buaTutorial:#Loading_scenarios| Loading scenarios]]
# [[Resources.B2buaTutorial:#B2BUA_scenario_format| B2BUA scenario format]]
# [[Resources.B2buaTutorial:#Scenario_examples| Scenario examples]]
# [[Resources.B2buaTutorial:#Configuration_file_example| Configuration file example]]

July 31, 2009, at 11:29 AM by anca_vamanu -

Changed lines 5-6 from:

(:toc-float Table of Content:)

to:

(:toc Table of Content:)

Changed lines 17-18 from:

!!1. Overview

to:

!! Overview

Changed lines 46-47 from:

!!2. Initiating B2B services

to:

!! Initiating B2B services

Changed lines 86-87 from:

!!3. Loading scenarios

to:

!! Loading scenarios

Changed line 97 from:

!!4. Scenario format

to:

!! Scenario format

Changed lines 225-226 from:

!!5. Scenario Examples

to:

!! Scenario Examples

Changed line 267 from:

!!6. Configuration file example

to:

!! Configuration file example

July 31, 2009, at 11:27 AM by anca_vamanu -

Added line 5:

(:toc-float Table of Content:)

July 23, 2009, at 11:56 AM by anca_vamanu -

Added line 24:

Changed line 192 from:

[[[<<]]

to:

[[<<]]

July 23, 2009, at 11:55 AM by anca_vamanu -

Changed lines 20-21 from:

* b2b_entities - implementing the behavior of UAC and UAS (B2BUA)
* b2b_logic - implementing a logic for analyzing and applying services scenarios to achieve the desired B2BUA specific services.

to:

* b2b_entities - the bottom half, implementing the behavior of UAC and UAS (B2BUA)
* b2b_logic - the upper half, implementing a logic for analyzing and applying services scenarios to achieve the desired B2BUA specific services.

July 23, 2009, at 11:50 AM by anca_vamanu -

Changed lines 36-37 from:

A scenario instantiation is an application of a scenario that is currently in progress. The b2b_logic module might be told to initialize a scenario in two ways: from the script, by calling a function that the module exports when an initial request is received, or by sending an external command. When receiving one of this two events, the b2b_logic module will create a record(corresponding to the red small boxes in the drawing) with the information for that scenario instantiation. Also at this moment, the b2b_logic module tells the b2b_entities module to create the entities(server and/or clients) that it requires. The record mainly stores a relation to the scenario document that it must follow, the state of the scenario application and the identifiers for the entities in b2b_entities module.

to:

The services are defined in documents called scenarios. A scenario instantiation is an application of a scenario that is currently in progress. The b2b_logic module might be told to initialize a scenario in two ways: from the script, by calling a function that the module exports when an initial request is received, or by sending an external command. When receiving one of this two events, the b2b_logic module will create a record(corresponding to the red small boxes in the drawing) with the information for that scenario instantiation. Also at this moment, the b2b_logic module tells the b2b_entities module to create the entities(server and/or clients) that it requires. The record mainly stores a relation to the scenario document that it must follow, the state of the scenario application and the identifiers for the entities in b2b_entities module.

Changed lines 39-47 from:

As can be seen in the picture, the b2b_entities module is the bottom half part of B2BUA and it deals with the actual network message exchange. To achieve this it uses directly the functions provided by the '''tm''' module for sending requests and replies and for receiving replies. Also the tm module announce it when a reply for a request that it has sent is received. For requests inside dialog, the b2b_entities module registers a prescript function that catches this requests. In the current implementation, this requests don't go into the script because the prescript function returns '0'. As mentioned earlier, when receiving a reply or request that is matched to a known dialog, the b2b_entities module does no further action but notifies the b2b_logic module about this event. The b2b_logic module will then decide what actions should be taken and sends back control commands to the b2b_entities module.

The services are defined in documents called scenarios. A certain scenario can be activated at the receipt of an initial request from the script or with an MI command.
This tutorial presents the information needed to use this feature grouped in the following chapters:

to:

As can be seen in the picture, the b2b_entities module is the bottom half part of B2BUA and it deals with the actual network message exchange. To achieve this it uses directly the functions provided by the '''tm''' module for sending requests and replies and for receiving replies. Also the tm module announce it when a reply for a request that it has sent is received. For requests inside dialog, the b2b_entities module registers a prescript function that catches this requests. In the current implementation, this requests don't go into the script because the prescript function returns '0'. As mentioned earlier, when receiving a reply or request that is matched to a known dialog, the b2b_entities module does no further action but notifies the b2b_logic module about this event. The b2b_logic module which is the upper half, will then decide what actions should be taken and sends back control commands to the b2b_entities module.

Changed lines 43-44 from:

!!1. Initiating B2B services

to:

!!2. Initiating B2B services

Changed lines 83-84 from:

!!2. Loading scenarios

to:

!!3. Loading scenarios

Changed line 94 from:

!!3. Scenario format

to:

!!4. Scenario format

Changed lines 222-223 from:

!!4. Scenario Examples

to:

!!5. Scenario Examples

Changed line 264 from:

!!5. Configuration file example

to:

!!6. Configuration file example

July 23, 2009, at 11:37 AM by anca_vamanu -

Added lines 6-16:

# [[Resources.B2buaTutorial:#Overview| Overview]]
# [[Resources.B2buaTutorial:#Initiating_B2B_services| Initiating B2B services]]
# [[Resources.B2buaTutorial:#Loading_scenarios| Loading scenarios]]
# [[Resources.B2buaTutorial:#B2BUA_scenario_format| B2BUA scenario format]]
# [[Resources.B2buaTutorial:#Scenario_examples| Scenario examples]]
# [[Resources.B2buaTutorial:#Configuration_file_example| Configuration file example]]

[[#Overview]]
!!1. Overview

Changed lines 39-41 from:

As can be seen in the picture, the b2b_entities module is the bottom half part of B2BUA and it deals with the actual network message exchange. To achieve this it uses directly the functions provided by the '''tm''' module for sending requests and replies and for receiving replies. Also the tm module announce it when a reply for a request that it has sent is received. For requests inside dialog, the b2b_entities module registers a prescript function that catches this requests. In the current implementation, this requests don't go into the script because the prescript function returns '0'. As mentioned earlier, when receiving a reply or request that is matched to a known dialog, the b2b_entities module does no further action but notifies the b2b_logic module about this event. The b2b_logic module will then decide what

to:

As can be seen in the picture, the b2b_entities module is the bottom half part of B2BUA and it deals with the actual network message exchange. To achieve this it uses directly the functions provided by the '''tm''' module for sending requests and replies and for receiving replies. Also the tm module announce it when a reply for a request that it has sent is received. For requests inside dialog, the b2b_entities module registers a prescript function that catches this requests. In the current implementation, this requests don't go into the script because the prescript function returns '0'. As mentioned earlier, when receiving a reply or request that is matched to a known dialog, the b2b_entities module does no further action but notifies the b2b_logic module about this event. The b2b_logic module will then decide what actions should be taken and sends back control commands to the b2b_entities module.

Changed lines 46-52 from:

# [[Resources.B2buaTutorial:#Initiating_B2B_services| Initiating B2B services]]
# [[Resources.B2buaTutorial:#Loading_scenarios| Loading scenarios]]
# [[Resources.B2buaTutorial:#B2BUA_scenario_format| B2BUA scenario format]]
# [[Resources.B2buaTutorial:#Scenario_examples| Scenario examples]]
# [[Resources.B2buaTutorial:#Configuration_file_example| Configuration file example]]

to:

Deleted lines 48-49:

July 23, 2009, at 11:28 AM by anca_vamanu -

Changed lines 6-7 from:

OpenSIPS has many features but in the way it behaves when a media session is established, it is not more than a proxy, meaning that it only takes the messages from one side and pass them on the other side. However, this has proven not to be enough as to provide certain services requires for the server to be aware of the state of the sessions, monitor and control them. A Back-to-Back User Agent is exactly this, a entity in the SIP network which has the ability to control or start media sessions. The name comes from the behavior, since in fact what is required is for the B2BUA to stand in the middle and establish two dialogs with both end points that will eventually exchange media.

to:

OpenSIPS has many features but in the way it behaves when a media session is established, it is not more than a proxy, meaning that it only takes the messages from one side and pass them on the other side. However, this has proven not to be enough as to provide certain services it is required for the server to be aware of the state of the sessions, monitor and control them. A Back-to-Back User Agent is exactly this, a entity in the SIP network which has the ability to control or start media sessions. The name comes from the behavior, since in fact what is required is for the B2BUA to stand in the middle and establish two dialogs with both end points that will eventually exchange media.

Changed lines 15-16 from:

The reason for which the architecture two parts is to allow extensions and integration with other system that might implement their own logic interpretor. Instead of the b2b_logic module, another module with a different logic interpretor or scenario source can be placed there and use the interface that the b2b_entities module offer to apply the scenarios and finally implement the features. The b2b_entities role in the processing is an independent one that is required in any B2B implementation and it is therefore encoded in a separate module so that offer an upper level library that will make the implementation of another logic interpreter and applier much easier. The separation enhances and encourages extension and development.

to:

The reason for which the architecture has two parts is to allow extensions and integration with other system that might implement their own logic interpretor. Instead of the b2b_logic module, another module with a different logic interpretor or scenario source can be placed there and use the interface that the b2b_entities module offers to build quickly a new B2BUA implementation. The b2b_entities role in the processing is an independent one that is required in any B2B implementation and it is therefore encoded in a separate module. It offer an upper level library that will make the implementation of another logic interpreter and applier much easier. The separation enhances and encourages extension and integration with other systems.

Changed lines 18-19 from:

Server Entity and Client Entity

to:

!!!Server Entity and Client Entity

Changed lines 21-23 from:

b2b server entity if it is created when a message is received and has to reply to it
b2b client entity if the entity will have to start a dialog by sending an initial message

to:

* b2b server entity if it is created when a message is received and has to reply to it
* b2b client entity if the entity will have to start a dialog by sending an initial message

Changed lines 25-26 from:

A scenario instantiation is an application of a scenario that is currently in process. The b2b_logic module might be told to initialize a scenario in two ways: from the script, by calling a function that the module exports when an initial request is received, or by sending an external command. When receiving one of this two events, the b2b_logic module will create a record(corresponding to the red small boxes in the drawing) with the information for that scenario instantiation. Also at this moment, the b2b_logic module tells the b2b_entities module to create the entities(server and/or clients) that it requires. The record mainly stores a relation to the scenario document that it must follow, the state of the scenario application and the identifiers for the entities in b2b_entities module.

to:

A scenario instantiation is an application of a scenario that is currently in progress. The b2b_logic module might be told to initialize a scenario in two ways: from the script, by calling a function that the module exports when an initial request is received, or by sending an external command. When receiving one of this two events, the b2b_logic module will create a record(corresponding to the red small boxes in the drawing) with the information for that scenario instantiation. Also at this moment, the b2b_logic module tells the b2b_entities module to create the entities(server and/or clients) that it requires. The record mainly stores a relation to the scenario document that it must follow, the state of the scenario application and the identifiers for the entities in b2b_entities module.

Changed line 28 from:

As can be seen in the picture, the b2b_entities module uses directly the functions provided by the tm module for sending requests and replies and for receiving replies. External commands will be received through the Management Interface from core which at its turn hides the transportation means that is used for sending the command.

to:

As can be seen in the picture, the b2b_entities module is the bottom half part of B2BUA and it deals with the actual network message exchange. To achieve this it uses directly the functions provided by the '''tm''' module for sending requests and replies and for receiving replies. Also the tm module announce it when a reply for a request that it has sent is received. For requests inside dialog, the b2b_entities module registers a prescript function that catches this requests. In the current implementation, this requests don't go into the script because the prescript function returns '0'. As mentioned earlier, when receiving a reply or request that is matched to a known dialog, the b2b_entities module does no further action but notifies the b2b_logic module about this event. The b2b_logic module will then decide what

July 22, 2009, at 07:15 PM by anca_vamanu -

Changed line 6 from:

OpenSIPS has many features but in the way it behaves when a media session is established, it is not more than a proxy, meaning that it only takes the messages from one side and pass them on the other side. However, this has proven not to be enough as it is necessary to support services which require the server to be aware of the state of the sessions, monitor and control them. A Back-to-Back User Agent is exactly this, a entity in the SIP network which has the ability to control or start media sessions. The name comes from the behavior, since in fact what is required is for the B2BUA to stand in the middle and establish two dialogs with both end points that will eventually exchange media.

to:

OpenSIPS has many features but in the way it behaves when a media session is established, it is not more than a proxy, meaning that it only takes the messages from one side and pass them on the other side. However, this has proven not to be enough as to provide certain services requires for the server to be aware of the state of the sessions, monitor and control them. A Back-to-Back User Agent is exactly this, a entity in the SIP network which has the ability to control or start media sessions. The name comes from the behavior, since in fact what is required is for the B2BUA to stand in the middle and establish two dialogs with both end points that will eventually exchange media.

July 22, 2009, at 07:14 PM by anca_vamanu -

Added lines 14-28:

The reason for which the architecture two parts is to allow extensions and integration with other system that might implement their own logic interpretor. Instead of the b2b_logic module, another module with a different logic interpretor or scenario source can be placed there and use the interface that the b2b_entities module offer to apply the scenarios and finally implement the features. The b2b_entities role in the processing is an independent one that is required in any B2B implementation and it is therefore encoded in a separate module so that offer an upper level library that will make the implementation of another logic interpreter and applier much easier. The separation enhances and encourages extension and development.

The two parts composing B2BUA in OpenSIPS are bound to each other in a control-notify relationship. The b2b_logic module controls the b2b_entities by sending commands and telling it what messages to send and the b2b_entities modules notifies the b2b_logic module when a request or a reply is received for a dialog that the B2B is handling.
Server Entity and Client Entity
The name represents in fact the type if transaction entity that is created at the beginning. So there will be a
b2b server entity if it is created when a message is received and has to reply to it
b2b client entity if the entity will have to start a dialog by sending an initial message

!!!Scenario Instantiation
A scenario instantiation is an application of a scenario that is currently in process. The b2b_logic module might be told to initialize a scenario in two ways: from the script, by calling a function that the module exports when an initial request is received, or by sending an external command. When receiving one of this two events, the b2b_logic module will create a record(corresponding to the red small boxes in the drawing) with the information for that scenario instantiation. Also at this moment, the b2b_logic module tells the b2b_entities module to create the entities(server and/or clients) that it requires. The record mainly stores a relation to the scenario document that it must follow, the state of the scenario application and the identifiers for the entities in b2b_entities module.

!!!Communication with the exterior
As can be seen in the picture, the b2b_entities module uses directly the functions provided by the tm module for sending requests and replies and for receiving replies. External commands will be received through the Management Interface from core which at its turn hides the transportation means that is used for sending the command.

July 22, 2009, at 07:10 PM by anca_vamanu -

Added lines 12-14:

The picture bellow shows the architecture of the B2BUA implementation.
http://www.opensips.org/images/B2BUA_architecture.jpg

July 22, 2009, at 07:08 PM by anca_vamanu -

Added lines 5-6:

OpenSIPS has many features but in the way it behaves when a media session is established, it is not more than a proxy, meaning that it only takes the messages from one side and pass them on the other side. However, this has proven not to be enough as it is necessary to support services which require the server to be aware of the state of the sessions, monitor and control them. A Back-to-Back User Agent is exactly this, a entity in the SIP network which has the ability to control or start media sessions. The name comes from the behavior, since in fact what is required is for the B2BUA to stand in the middle and establish two dialogs with both end points that will eventually exchange media.

July 22, 2009, at 05:24 PM by anca_vamanu -

Added line 46:

_empty_line_

July 22, 2009, at 05:17 PM by anca_vamanu -

Changed line 24 from:

!!1. Instantiating B2B services

to:

!!1. Initiating B2B services

July 22, 2009, at 05:12 PM by anca_vamanu -

Added line 85:

[[<<]]

Changed line 123 from:

to:

[[<<]]

Changed lines 126-128 from:

|| Value source || Value type || Example ||
|| Inline URI || "uri" ||<pre><destination>    <value type="uri">sip:ms@opensips.org</value> </destination></pre>||
|| Parameter.The value node content is a number and represents the number of the parameter.||"param"||<pre><destination>    <value type="param">1</value> </destination></pre>||

to:

||Value source||Value type||Example||
||Inline URI ||"uri" ||<pre><destination>    <value type="uri">sip:ms@opensips.org</value> </destination></pre>||
||Parameter.The value node content is a number and represents the number of the parameter.||"param"||<pre><destination>    <value type="param">1</value> </destination></pre>||

Changed line 157 from:

[<<]

to:

[[<<]]

Changed line 171 from:

[<<]

to:

[[[<<]]

Deleted line 172:

[<<]

Changed line 182 from:

[<<]

to:

[[<<]]

Changed line 184 from:

[<<]

to:

Changed line 193 from:

[<<]

to:

[[<<]]

Deleted line 194:

[<<]

July 22, 2009, at 05:08 PM by anca_vamanu -

Added line 85:

%color=#ff7f00% Ex: %black%'''Scenario root node example'''

Added lines 116-117:

[[<<]]
%color=#ff7f00% Ex: %black%'''Scenario destination node example'''

Changed line 123 from:

to:

%color=#ff7f00% Table: %black%'''Scenario destination node structure'''

Changed lines 135-136 from:

Below there are two examples of scenario init parts, one that creates entities based on a received message and in which the dialog is initiated by the b2bua that puts two entities in contact.

to:

Below there are two examples of scenario init parts, one that creates entities based on a received message and in
which the dialog is initiated by the b2bua that puts two entities in contact.

[[<<]]
%color=#ff7f00% Table: %black%'''Scenario init node examples'''

Added lines 155-156:

%color=#ff7f00% Ex: %black%'''Scenario rules node structure'''
[<<]

Added lines 170-172:

[<<]
%color=#ff7f00% Ex: %black%'''Scenario condition node'''
[<<]

Added lines 182-184:

[<<]
%color=#ff7f00% Table: %black%'''Scenario rules node structure'''
[<<]

Added lines 193-195:

[<<]
%color=#ff7f00% Ex: %black%'''Scenario action node'''
[<<]

July 22, 2009, at 04:56 PM by anca_vamanu -

Changed line 245 from:

modparam("tm", "pass_provisional_replies", 1)

to:

<pre>modparam("tm", "pass_provisional_replies", 1)</pre>

July 22, 2009, at 04:51 PM by anca_vamanu -

Changed lines 40-48 from:

>>lframe blue<<
:b2b_trigger_scenario:fifo_reply
[<<]
marketing
[<<]
sip:bob@opensips.org
[<<]
sip:322@opensips.org:5070
[<<]

to:

>>lframe black<<
:b2b_trigger_scenario[=:=]fifo_reply[[<<]]
marketing[[<<]]
sip:bob@opensips.org[[<<]]
sip:322@opensips.org:5070[[<<]]

Changed lines 55-58 from:

>>lframe blue<<
[@
if(is_method("INVITE") && src_ip=="10.10.10.10")
b2b_init_request("top hiding");@]

to:

>>lframe<<
<pre>if(is_method("INVITE") && src_ip=="10.10.10.10")    b2b_init_request("top hiding");</pre>

Changed lines 68-70 from:

>>lframe blue<<
[@modparam("b2b_logic", "script_scenario", "/usr/local/opensips/etc/b2bua/scenario_script.xml")
modparam("b2b_logic", "extern_scenario", "/usr/local/opensips/etc/b2bua/scenario_extern.xml")@]

to:

>>lframe<<
<pre>modparam("b2b_logic", "script_scenario", "/usr/local/opensips/etc/b2bua/scenario_script.xml") modparam("b2b_logic", "extern_scenario", "/usr/local/opensips/etc/b2bua/scenario_extern.xml")</pre>

July 22, 2009, at 04:43 PM by anca_vamanu -

Changed lines 41-44 from:

:b2b_trigger_scenario:fifo_reply\\
marketing\\
sip:bob@opensips.org\\
sip:322@opensips.org:5070\\

to:

:b2b_trigger_scenario:fifo_reply
[<<]
marketing
[<<]
sip:bob@opensips.org
[<<]
sip:322@opensips.org:5070
[<<]

July 22, 2009, at 04:41 PM by anca_vamanu -

Changed lines 40-45 from:

>>lframe blue<<
[@:b2b_trigger_scenario:fifo_reply
marketing
sip:bob@opensips.org
sip:322@opensips.org:5070
sip:alice@opensips.org@]

to:

>>lframe blue<<
:b2b_trigger_scenario:fifo_reply\\
marketing\\
sip:bob@opensips.org\\
sip:322@opensips.org:5070\\
sip:alice@opensips.org

July 22, 2009, at 04:40 PM by anca_vamanu -

Changed line 40 from:

>>blue<<

to:

>>lframe blue<<

July 22, 2009, at 04:39 PM by anca_vamanu -

Changed line 40 from:

>>lframe blue<<

to:

>>blue<<

Added line 118:

>>lframe<<

Changed lines 120-121 from:

to:

>><<
[[<<]]

Added line 152:

>>lframe<<

Changed lines 154-155 from:

to:

>><<
[[<<]]

Added line 165:

>>lframe<<

Changed lines 167-170 from:

to:

>><<
[[<<]]

Added line 182:

>>lframe<<

Changed lines 184-187 from:

to:

>><<
[[<<]]

Added line 209:

>>lframe<<

Changed lines 211-213 from:

to:

>><<
[[<<]]

Added line 225:

>>lframe<<

Added lines 227-228:

>><<
[[<<]]

July 22, 2009, at 04:36 PM by anca_vamanu -

Changed line 88 from:

to:

>>lframe<<

Changed lines 90-91 from:

to:

>><<
[[<<]]

July 22, 2009, at 04:35 PM by anca_vamanu -

Changed line 6 from:

B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers the possibility to build certain services on top of it.It consists of two modules which folow exctly this separation:

to:

B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers the possibility to build certain services on top of it. It consists of two modules:

Changed line 8 from:

* b2b_logic - implementing a logic for analyzing and applying services scenarios to achieve the desired B2BUA specific services

to:

* b2b_logic - implementing a logic for analyzing and applying services scenarios to achieve the desired B2BUA specific services.

July 22, 2009, at 03:39 PM by anca_vamanu -

Added lines 223-229:

Also please note that you need to configure the tm module to pass provisional replies. For this you need to set the module parameter:

>>lframe blue<<
modparam("tm", "pass_provisional_replies", 1)
>><<
[[<<]]

July 22, 2009, at 03:28 PM by anca_vamanu -

Added line 224:

You can find [[b2b_config_example|here]] a configuration file example that loads the two scenarios presented in this tutorial and enables the '''prepaid''' service for a certain user. Also the mi_fifo module is loaded here and it will be possible to send MI commands to instantiate the '''marketing''' scenario.

July 22, 2009, at 03:24 PM by anca_vamanu -

Added lines 220-223:

* load a MI module if you need to support triggering B2BUA scenarios with extern commands. Depending on the transport you require, either mi_fifo or mi_xmlrpc or mi_datagram.
* built the filters and call the script scenario instantiating function

July 22, 2009, at 03:20 PM by anca_vamanu -

Changed lines 65-66 from:

!! Loading scenarios

to:

!!2. Loading scenarios

Changed line 77 from:

!! Scenario format

to:

!!3. Scenario format

Changed lines 174-175 from:

!!Scenario Examples

to:

!!4. Scenario Examples

Changed line 210 from:

!!Configuration file example

to:

!!5. Configuration file example

July 22, 2009, at 03:17 PM by anca_vamanu -

Added lines 208-219:

[[#Configuration_file_example]]
!!Configuration file example

There are some requirements for a configuration file that enables the B2BUA services.

* load modules '''b2b_entities''' and '''b2b_logic'''
* set module parameters
** compulsory: the '''server_address''' parameter in b2b_entities
** optional:
*** '''script_scenario''' and '''extern_scenario''' in b2b_logic for loading service scenarios
*** parameters for the hash tables - server_hsize and client_hsize in b2b_entities module and '''hash_size''' in b2b_logic module

July 22, 2009, at 03:00 PM by anca_vamanu -

Added lines 200-204:

The id which must be mentioned to start this service is 'marketing'. It requires 3 parameters
* the URI of the possible costumer
* the URI of the media server
* the URI of the human operator

July 22, 2009, at 02:52 PM by anca_vamanu -

Added lines 176-178:

In this section there are presented two scenario examples, one that can be triggered from the script and one for the MI command.

Changed lines 188-193 from:

The scenario document that describes this service is the one printed bellow:

to:

In B2BUA terms, this is a script scenario that can be instantiating by specifying the id '''prepaid'''. It requires 2 parameters:
* the location of the first media server
* the location of the second media server

The full scenario document is printed bellow:

July 22, 2009, at 01:24 PM by anca_vamanu -

Changed lines 22-24 from:

!! Instantiating B2B services

to:

!!1. Instantiating B2B services

July 22, 2009, at 01:18 PM by anca_vamanu -

Changed line 70 from:

modparam("b2b_logic", "extern_scenario", "//usr/local/opensips/etc/b2bua/scenario_extern.xml")@]

to:

modparam("b2b_logic", "extern_scenario", "/usr/local/opensips/etc/b2bua/scenario_extern.xml")@]

July 22, 2009, at 01:18 PM by anca_vamanu -

Changed lines 69-70 from:

[@modparam("b2b_logic", "script_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_script.xml")
modparam("b2b_logic", "extern_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_extern.xml")@]

to:

[@modparam("b2b_logic", "script_scenario", "/usr/local/opensips/etc/b2bua/scenario_script.xml")
modparam("b2b_logic", "extern_scenario", "//usr/local/opensips/etc/b2bua/scenario_extern.xml")@]

July 22, 2009, at 01:17 PM by anca_vamanu -

Changed line 52 from:

%color=#ff7f00% Ex:

to:

%color=#ff7f00% Ex:%black% '''Calling top hiding service'''

Changed lines 54-56 from:

[@b2b_init_request("top hiding");@]

to:

[@
if(is_method("INVITE") && src_ip=="10.10.10.10")
b2b_init_request("top hiding");@]

July 22, 2009, at 01:14 PM by anca_vamanu -

Changed lines 67-68 from:

modparam("b2b_logic", "script_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_script.xml")
modparam("b2b_logic", "extern_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_extern.xml")

to:

[@modparam("b2b_logic", "script_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_script.xml")
modparam("b2b_logic", "extern_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_extern.xml")@]

July 22, 2009, at 01:14 PM by anca_vamanu -

Changed lines 6-10 from:

B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers the possibility to build certain services on top of it. The services are defined in documents called scenarios. A certain scenario can be activated at the receipt of an initial request from the script or with an MI command.

to:

B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers the possibility to build certain services on top of it.It consists of two modules which folow exctly this separation:
* b2b_entities - implementing the behavior of UAC and UAS (B2BUA)
* b2b_logic - implementing a logic for analyzing and applying services scenarios to achieve the desired B2BUA specific services

The services are defined in documents called scenarios. A certain scenario can be activated at the receipt of an initial request from the script or with an MI command.

Deleted line 36:

Changed lines 57-59 from:

Other services must be defined in scenario documents which structure is described bellow and loaded at startup by providing the path towards them as module parameters as presented in the following chapter.

to:

Other services must be defined in scenario documents and loaded at startup by providing the path towards them as module parameters as presented in the following chapter.

Added lines 62-70:

The scenario documents are loaded at startup and their paths in the system must be provided through module parameters that belong to the b2b_logic module. There are two parameters, one of each type of scenario: '''scenario_script''' and '''scenario_extern'''.

%color=#ff7f00% Ex:%black% '''Loading B2BUA scenarios'''
>>lframe blue<<
modparam("b2b_logic", "script_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_script.xml")
modparam("b2b_logic", "extern_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_extern.xml")
>><<
[[<<]]

July 22, 2009, at 12:54 PM by anca_vamanu -

Changed lines 32-39 from:

%color=#ff7f00% Ex: %black%'''Fifo MI command'''\\
||border=1
||blue%:b2b_trigger_scenario:fifo_reply\\
%blue%marketing\\
%blue%sip:bob@opensips.org\\
%blue%sip:322@opensips.org:5070\\
%blue%sip:alice@opensips.org||

to:

%color=#ff7f00% Ex: %black%'''Fifo MI command'''
>>lframe blue<<
[@:b2b_trigger_scenario:fifo_reply
marketing
sip:bob@opensips.org
sip:322@opensips.org:5070
sip:alice@opensips.org@]
>><<

[[<<]]
[[<<]]

Added line 48:

Changed lines 50-51 from:

b2b_init_request("top hiding");

to:

>>lframe blue<<
[@b2b_init_request("top hiding");@]
>><<
[[<<]]

July 22, 2009, at 12:35 PM by anca_vamanu -

Changed lines 33-34 from:

||\\
%blue%:b2b_trigger_scenario:fifo_reply\\

to:

||border=1
||blue%:b2b_trigger_scenario:fifo_reply\\

Changed lines 38-39 from:

%blue%sip:alice@opensips.org\\
||

to:

%blue%sip:alice@opensips.org||

July 22, 2009, at 12:34 PM by anca_vamanu -

Changed line 33 from:

---\\

to:

||\\

Changed line 39 from:

---

to:

||

July 22, 2009, at 12:34 PM by anca_vamanu -

Changed lines 32-33 from:

%color=#ff7f00% Ex: \\
'''Fifo MI command'''\\

to:

%color=#ff7f00% Ex: %black%'''Fifo MI command'''\\

July 22, 2009, at 12:33 PM by anca_vamanu -

Changed lines 32-35 from:

%color=#ff7f00% Ex:

'''Fifo MI command'''
---

to:

%color=#ff7f00% Ex: \\
'''Fifo MI command'''\\
---\\

July 22, 2009, at 12:33 PM by anca_vamanu -

Changed lines 36-40 from:

%blue%:b2b_trigger_scenario:fifo_reply
%blue%marketing
%blue%sip:bob@opensips.org
%blue%sip:322@opensips.org:5070
%blue%sip:alice@opensips.org

to:

%blue%:b2b_trigger_scenario:fifo_reply\\
%blue%marketing\\
%blue%sip:bob@opensips.org\\
%blue%sip:322@opensips.org:5070\\
%blue%sip:alice@opensips.org\\

July 22, 2009, at 12:31 PM by anca_vamanu -

Added line 31:

Added line 33:

Deleted line 34:

[@

Changed lines 36-40 from:

:b2b_trigger_scenario:fifo_reply
marketing
sip:bob@opensips.org
sip:322@opensips.org:5070
sip:alice@opensips.org

to:

%blue%:b2b_trigger_scenario:fifo_reply
%blue%marketing
%blue%sip:bob@opensips.org
%blue%sip:322@opensips.org:5070
%blue%sip:alice@opensips.org

Deleted line 41:

@]

July 22, 2009, at 12:29 PM by anca_vamanu -

Changed lines 24-27 from:

The function that can be called from the script has the following prototype:

=cpp [= int b2b_init_request (struct sip_msg* msg, str* scenario_name, str* param1, str* param2, str* param3, str* param4, str* param5);=]

to:

The function that can be called from the script has the name '''b2b_init_request''' and has 6 parameters:

'''b2b_init_request''' ( scenario_name, param1, param2, param3, param4, param5)

Changed lines 30-31 from:

The MI command has the name '''b2b_trigger_scenario''' and as the script function it takes maximum 6 arguments, the first one being the name of the scenario.

to:

The MI command has the name '''b2b_trigger_scenario''' and takes exactly the same parameters as the script function.
%color=#ff7f00% Ex:
'''Fifo MI command'''
[@
---
:b2b_trigger_scenario:fifo_reply
marketing
sip:bob@opensips.org
sip:322@opensips.org:5070
sip:alice@opensips.org
---
@]

There is one predefined service that works without any scenario definition and for any type of dialog. This is '''topology hiding''' service. The functionality is obvious from the name and what this service does is to hide the network topology from the parties that establish a dialog. To achieve this, the B2BUA poses itself in the middle and established dialogs with both parties. Then all it will do next will be to translate a receipt request or reply into the dialog from the other side and forward it to the peer entity.

This service can only be selected from the script, because it has sense only when a dialog is initiated. It does not require any parameter. The id for this scenario is '''top hiding'''.
%color=#ff7f00% Ex:
b2b_init_request("top hiding");

Other services must be defined in scenario documents which structure is described bellow and loaded at startup by providing the path towards them as module parameters as presented in the following chapter.

July 22, 2009, at 11:30 AM by anca_vamanu -

Added lines 28-31:

The first parameter is the name of the scenario to be instantiated. So it is the job of the script writer to decide when a certain scenario should be applied . The next arguments are parameters needed by the scenario. As it shall be seen later, a scenario can require some values to be given as parameters in contrast to hard coding them, making the scenario configurable.

The MI command has the name '''b2b_trigger_scenario''' and as the script function it takes maximum 6 arguments, the first one being the name of the scenario.

July 22, 2009, at 11:27 AM by anca_vamanu -

Changed line 26 from:

=cpp [=int '''b2b_init_request'''(struct sip_msg* msg, str* scenario_name, str* param1, str* param2, str* param3, str* param4, str* param5);=]

to:

=cpp [= int b2b_init_request (struct sip_msg* msg, str* scenario_name, str* param1, str* param2, str* param3, str* param4, str* param5);=]

July 22, 2009, at 11:26 AM by anca_vamanu -

Added line 12:

# [[Resources.B2buaTutorial:#B2BUA_scenario_format| B2BUA scenario format]]

Deleted lines 16-17:

The OpenSIPS B2BUA services have to be defined in scenario documents that have a certain structure that will be described in this tutorial. Also at the end of the tutorial there are presented two examples of scenarios, one that interposes recorded messages before and after the actual call and one in which the B2BUA connects two parties in a call.

Changed lines 18-19 from:

!! Instantiating a scenario

to:

!! Instantiating B2B services

There are two ways to trigger a B2B service.
* from script
* with an MI command

The function that can be called from the script has the following prototype:

=cpp [=int '''b2b_init_request'''(struct sip_msg* msg, str* scenario_name, str* param1, str* param2, str* param3, str* param4, str* param5);=]

Added lines 31-33:

!! Loading scenarios

[[#B2BUA_scenario_format]]

July 22, 2009, at 11:09 AM by anca_vamanu -

Changed line 18 from:

[#Initiating_B2B_services]

to:

[[#Initiating_B2B_services]]

Changed line 21 from:

[#Loading_scenarios]

to:

[[#Loading_scenarios]]

Changed line 118 from:

[#Scenario_examples]

to:

[[#Scenario_examples]]

July 22, 2009, at 11:07 AM by anca_vamanu -

Changed lines 4-5 from:

!!!Back-to-Back User Agent

to:

!Back-to-Back User Agent

Changed lines 19-20 from:

! Instantiating a scenario

to:

!! Instantiating a scenario

Changed line 22 from:

! Scenario format

to:

!! Scenario format

Changed line 31 from:

!! Scenario root

to:

!!! Scenario root

Changed lines 119-121 from:

!Scenario Examples

!! Prepaid

to:

!!Scenario Examples

!!! Prepaid

Changed line 133 from:

!! Marketing

to:

!!! Marketing

July 22, 2009, at 11:01 AM by anca_vamanu -

Changed lines 10-15 from:

# [[Resources.B2BUA:#Initiating_B2B_services| Initiating B2B services]]
# [[Resources.B2BUA:#Loading_scenarios| Loading scenarios]]
# [[Resources.B2BUA:#Scenario_examples| Scenario example]]
# [[Resources.B2BUA:#Configuration_file_example| Configuration file example]]

to:

# [[Resources.B2buaTutorial:#Initiating_B2B_services| Initiating B2B services]]
# [[Resources.B2buaTutorial:#Loading_scenarios| Loading scenarios]]
# [[Resources.B2buaTutorial:#Scenario_examples| Scenario examples]]
# [[Resources.B2buaTutorial:#Configuration_file_example| Configuration file example]]

Added lines 18-21:

[#Initiating_B2B_services]
! Instantiating a scenario

[#Loading_scenarios]

Changed lines 29-32 from:

!! Instantiating a scenario

to:

Added line 118:

[#Scenario_examples]

July 22, 2009, at 10:57 AM by anca_vamanu -

Changed line 12 from:

# [[Resources.B2BUA:#Scenario examples| Scenario example]]

to:

# [[Resources.B2BUA:#Scenario_examples| Scenario example]]

July 22, 2009, at 10:57 AM by anca_vamanu -

Changed line 6 from:

B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers building certain services on top of it. The services are defined in documents called scenarios. A certain scenario can be activated at the receipt of an initial request from the script or with an MI command.

to:

B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers the possibility to build certain services on top of it. The services are defined in documents called scenarios. A certain scenario can be activated at the receipt of an initial request from the script or with an MI command.

July 22, 2009, at 10:56 AM by anca_vamanu -

Changed lines 2-13 from:

!!Back-to-Back User Agent

to:

----

!!!Back-to-Back User Agent

B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers building certain services on top of it. The services are defined in documents called scenarios. A certain scenario can be activated at the receipt of an initial request from the script or with an MI command.
This tutorial presents the information needed to use this feature grouped in the following chapters:

# [[Resources.B2BUA:#Initiating_B2B_services| Initiating B2B services]]
# [[Resources.B2BUA:#Loading_scenarios| Loading scenarios]]
# [[Resources.B2BUA:#Scenario examples| Scenario example]]
# [[Resources.B2BUA:#Configuration_file_example| Configuration file example]]

July 21, 2009, at 06:22 PM by anca_vamanu -

Added lines 13-16:

!! Instantiating a scenario

July 21, 2009, at 06:07 PM by anca_vamanu -

July 21, 2009, at 06:06 PM by anca_vamanu -

Changed lines 113-198 from:

[@
<?xml version="1.0"?>
<scenario id="prepaid" name="MS start and end" param="2" type="script">
<init>
<bridge>
<server>
<id>server1</id>
</server>
<client>
<id>client1</id>
<type>message</type>
<destination>
<value type="param">1</value>
</destination>
</client>
</bridge>
<state>1</state>
</init>
<rules>
<request>
<bye>
<rule id="1">
<condition>
<state>1</state>
<sender>
<type>client</type>
<id>client1</id>
</sender>
</condition>
<action>
<send_reply>
<code>200</code>
<reason>OK</reason>
</send_reply>
<delete_entity/>
<bridge>
<client>
<id>server1</id>
</client>
<client>
<id>client2</id>
<destination>
<value type="initial">server1</value>
</destination>
</client>
</bridge>
<state>2</state>
</action>
</rule>

<rule id="2">
<condition>
<state>2</state>
<sender>
<type>client</type>
<id>client2</id>
</sender>
</condition>

<action>
<send_reply>
<code>200</code>
<reason>OK</reason>
</send_reply>
<delete_entity/>
<bridge>
<client>
<id>server1</id>
</client>
<client>
<id>client3</id>
<destination>
<value type="param">2</value>
</destination>
</client>
</bridge>
<state>3</state>
</action>
</rule>
</bye>
</request>
</rules>
</scenario>
@]

to:

<pre><?xml version="1.0"?> <scenario id="prepaid" name="MS start and end" param="2" type="script">      <init>          <bridge>             <server>                 <id>server1</id>             </server>             <client>                 <id>client1</id>                 <type>message</type>                 <destination>                     <value type="param">1</value>                 </destination>             </client>          </bridge>     <state>1</state>      </init>      <rules>          <request>              <bye>                  <rule id="1">                      <condition>                          <state>1</state>                          <sender>                              <type>client</type>                              <id>client1</id>                          </sender>                      </condition>                      <action>                          <send_reply>                              <code>200</code>                              <reason>OK</reason>                          </send_reply>                          <delete_entity/>                          <bridge>                              <client>                                  <id>server1</id>                              </client>                              <client>                                  <id>client2</id>                                  <destination>                                      <value type="initial">server1</value>                                  </destination>                              </client>                          </bridge>                          <state>2</state>                      </action>                  </rule>                  <rule id="2">                     <condition>                         <state>2</state>                         <sender>                             <type>client</type>                             <id>client2</id>                         </sender>                     </condition>                     <action>                         <send_reply>                             <code>200</code>                              <reason>OK</reason>                         </send_reply>                          <delete_entity/>                          <bridge>                              <client>                                  <id>server1</id>                              </client>                               <client>                                   <id>client3</id>                                   <destination>                                       <value type="param">2</value>                                   </destination>                               </client>                          </bridge>                          <state>3</state>                      </action>                  </rule>             </bye>         </request>     </rules> </scenario> </pre>

Changed lines 121-178 from:

[@
<?xml version="1.0"?>
<scenary id="marketing" name="MS start conditional" param="3" type="extern">
<init>
<bridge>
<client>
<id>client1</id>
<destination>
<value type="param">1</value>
</destination>
</client>
<client>
<id>client2</id>
<destination>
<value type="param">2</value>
</destination>
</client>
</bridge>
<state>1</state>
</init>

<rules>
<request>
<bye>
<rule id="1">
<condition>
<state>1</state>
<sender>
<type>client</type>
<id>client2</id>
</sender>
</condition>
<action>
<send_reply>
<code>200</code>
<reason>OK</reason>
</send_reply>
<delete_entity/>
<bridge>
<client>
<id>client1</id>
</client>
<client>
<id>client3</id>
<destination>
<value type="param">3</value>
</destination>
</client>
</bridge>
<state>2</state>
</action>
</rule>
</bye>
</request>
</rules>
</scenario>
@]

to:

<pre><?xml version="1.0"?> <scenary id="marketing" name="MS start conditional" param="3" type="extern">   <init>     <bridge>     <client>         <id>client1</id>         <destination>            <value type="param">1</value>         </destination>     </client>     <client>         <id>client2</id>         <destination>            <value type="param">2</value>         </destination>     </client>     </bridge>     <state>1</state>   </init>   <rules>     <request>        <bye>           <rule id="1">              <condition>                 <state>1</state>                 <sender>                    <type>client</type>                    <id>client2</id>                 </sender>              </condition>              <action>              <send_reply>                 <code>200</code>                 <reason>OK</reason>              </send_reply>              <delete_entity/>              <bridge>                 <client>                    <id>client1</id>                 </client>                 <client>                    <id>client3</id>                    <destination>                       <value type="param">3</value>                    </destination>                 </client>              </bridge>              <state>2</state>              </action>              </rule>          </bye>       </request>    </rules> </scenario></pre>

July 21, 2009, at 06:04 PM by anca_vamanu -

Changed line 96 from:

||state||Specifies the state the scenario instantiation will enter after the action will be executed.||<state>2</state>||

to:

||state||Specifies the state the scenario instantiation will enter after the action will be executed.||<pre><state>2</state></pre>||

July 21, 2009, at 06:03 PM by anca_vamanu -

Changed lines 86-95 from:

=xml [=
<condition>
� �<state>1</state>
� �<sender>
� � � <type>client</type>
� � � <id>client1</id>
� �</sender>
</condition>
=]

to:

<pre><condition>    <state>1</state>    <sender>       <type>client</type>       <id>client1</id>    </sender> </condition></pre>

Changed lines 93-111 from:

||send_reply||This node tells the B2BUA to send a reply to the sender of the current message. A code and reason sub node must be defined.||[@
<send_reply>
<code>200</code>
<reason>OK</reason>
</send_reply> @]||
||delete_entity||The delete_entity node specifies to the B2B Logic that the current entity which has received the message can be deleted.||<delete_entity/>||
||bridge||A bridge action means putting two end points in contact. The syntax is the same as the on for the bridge node in the init part. The only difference here is that the entities can be also existing ones. If a new entity is defined a destination node must be present.||[@
<bridge>
<client>
<id>client1</id>
</client>
<client>
<id>client3</id>
<destination>
<value type="param">
3</value>
</destination>
</client>
</bridge> @]||

to:

||send_reply||This node tells the B2BUA to send a reply to the sender of the current message. A code and reason sub node must be defined.||<pre><send_reply>   <code>200</code>   <reason>OK</reason> </send_reply></pre>||
||delete_entity||The delete_entity node specifies to the B2B Logic that the current entity which has received the message can be deleted.||<pre><delete_entity/></pre>||
||bridge||A bridge action means putting two end points in contact. The syntax is the same as the on for the bridge node in the init part. The only difference here is that the entities can be also existing ones. If a new entity is defined a destination node must be present.||<pre><bridge>  <client>    <id>client1</id>  </client>  <client>    <id>client3</id>    <destination>      <value type="param">      3</value>  </destination>  </client> </bridge></pre>||

Changed lines 99-120 from:

=xml [=
<action>
� � <send_reply>
� � � <code>200</code>
� � � <reason>OK</reason>
� � </send_reply>
� � <delete_entity/>
� � <bridge>
� � � <client>
� � � � <id>server1</id>
� � � </client>
� � � <client>
� � � � <id>client2</id>
� � � � <destination>
� � � � � <value type="initial">server1</value>
� � � � </destination>
� � � </client>
� � </bridge>
� � <state>2</state>
</action>
=]

to:

<pre><action>     <send_reply>       <code>200</code>       <reason>OK</reason>     </send_reply>     <delete_entity/>     <bridge>       <client>         <id>server1</id>       </client>       <client>         <id>client2</id>         <destination>           <value type="initial">server1</value>         </destination>       </client>     </bridge>     <state>2</state> </action></pre>

July 21, 2009, at 05:59 PM by anca_vamanu -

Changed lines 76-91 from:

=xml [=
<rules>
� <request>
� � <bye>
� � � <rule id= �1�>
...
� � � </rule>
� � � <rule id= �2�>
...
� � � </rule>
� � </bye>
� </request>
</rules>

=]

to:

July 21, 2009, at 05:57 PM by anca_vamanu -

Changed line 63 from:

||<pre><init>    <bridge>       <server>          <id>server1</id>       </server>       <client>          <id>client1</id>          <type>message</type>          <destination>             <value type="param">1</value>          </destination>       </client>    </bridge>    <state>1</state> </init> </pre>||[@ style="color: #660;">>      <bridge>           <client>                <id>client1</id>                <destination>                     <value type="param">1</value>                </destination>           </client>                     <client>                <id>client2</id>                <destination>                     <value type="param">2</value>                </destination>           </client>      </bridge>        <state>1</state> </init></pre>||

to:

||<pre><init>    <bridge>       <server>          <id>server1</id>       </server>       <client>          <id>client1</id>          <type>message</type>          <destination>             <value type="param">1</value>          </destination>       </client>    </bridge>    <state>1</state> </init> </pre>||<pre><init>      <bridge>           <client>                <id>client1</id>                <destination>                     <value type="param">1</value>                </destination>           </client>                     <client>                <id>client2</id>                <destination>                     <value type="param">2</value>                </destination>           </client>      </bridge>        <state>1</state> </init></pre>||

July 21, 2009, at 05:54 PM by anca_vamanu -

Changed lines 63-103 from:

||[@<init>
<bridge>

<server>
<id>server1</id>
</server>

<client>
<id>client1</id>
<type>message</type>
<destination>
<value type="param">1</value>
</destination>
</client>

</bridge>

<state>1</state>
</init> @]||[@ <init>
<bridge>
<client>
<id>client1</id>
<destination>
<value type="param">1</value>
</destination>
</client>

<client>
<id>client2</id>

<destination>
<value type="param">2</value>
</destination>
</client>

</bridge>

<state>1</state>
</init> @]||

to:

||<pre><init>    <bridge>       <server>          <id>server1</id>       </server>       <client>          <id>client1</id>          <type>message</type>          <destination>             <value type="param">1</value>          </destination>       </client>    </bridge>    <state>1</state> </init> </pre>||[@ style="color: #660;">>      <bridge>           <client>                <id>client1</id>                <destination>                     <value type="param">1</value>                </destination>           </client>                     <client>                <id>client2</id>                <destination>                     <value type="param">2</value>                </destination>           </client>      </bridge>        <state>1</state> </init></pre>||

July 21, 2009, at 05:49 PM by anca_vamanu -

Changed line 50 from:

|| Inline URI || "uri" || <pre><destination>    <value type="uri">sip:ms@opensips.org</value> </destination></pre>||

to:

|| Inline URI || "uri" ||<pre><destination>    <value type="uri">sip:ms@opensips.org</value> </destination></pre>||

July 21, 2009, at 05:49 PM by anca_vamanu -

Changed lines 50-52 from:

|| Inline URI || "uri" ||<destination><value type="uri">sip:ms@opensips.org</value></destination> ||
|| Parameter.The value node content is a number and represents the number of the parameter.||"param"||<destination><value type="param">1</value></destination>||
||Initial destination.Used when the bridging is based on a received message. The destination will be that from the message.||"initial"||<destination><value type="initial"></value></destination>||

to:

|| Inline URI || "uri" || <pre><destination>    <value type="uri">sip:ms@opensips.org</value> </destination></pre>||
|| Parameter.The value node content is a number and represents the number of the parameter.||"param"||<pre><destination>    <value type="param">1</value> </destination></pre>||
||Initial destination.Used when the bridging is based on a received message. The destination will be that from the message.||"initial"||<pre><destination>    <value type="initial"></value> </destination></pre>||

July 21, 2009, at 05:35 PM by anca_vamanu -

Changed lines 45-50 from:

=xml [=
<destination>
<value type="_value_type_">_value_</value>
</destination>
=]

to:

<pre><destination>    <value type="_value_type_">_value_</value> </destination></pre>

July 21, 2009, at 05:34 PM by anca_vamanu -

Changed line 17 from:

to:

July 21, 2009, at 05:33 PM by anca_vamanu -

Changed lines 17-20 from:

=xml [=
<scenario id="prepaid" name="MS start and end" param="2"type="script">
=]

to:

July 21, 2009, at 12:51 PM by anca_vamanu -

Changed line 5 from:

The OpenSIPS B2BUA services have to be defined in scenario documents that have a certain strcture.

to:

The OpenSIPS B2BUA services have to be defined in scenario documents that have a certain structure that will be described in this tutorial. Also at the end of the tutorial there are presented two examples of scenarios, one that interposes recorded messages before and after the actual call and one in which the B2BUA connects two parties in a call.

July 21, 2009, at 12:49 PM by anca_vamanu -

Changed line 1 from:

!!Resources -> [[Resources.Documentation | Documentation]] -> B2BUA

to:

!!Resources -> [[Resources.Documentation | Documentation]] -> [[Resources.DocsTutorials | Tutorials]]-> B2BUA

July 21, 2009, at 12:47 PM by anca_vamanu -

Changed lines 1-2 from:

The OpenSIPS B2BUA services have to be defined in scenario documents.

to:

!!Resources -> [[Resources.Documentation | Documentation]] -> B2BUA
!!Back-to-Back User Agent

The OpenSIPS B2BUA services have to be defined in scenario documents that have a certain strcture.

Changed line 10 from:

A scenario is a predefined behavior that will be interpreted by the B2B Logic. The decision when the the scenario will be applied must be taken by the server administrator in the configuration file or triggered by an extern application.

to:

A scenario is a predefined behavior that will be interpreted by the B2B Logic. The decision when the the scenario will be applied must be taken by the server administrator in the configuration file or triggered by an extern application with an MI command.

July 20, 2009, at 08:00 PM by anca_vamanu -

Changed line 216 from:

=xml [=

to:

[@

Changed lines 299-300 from:

=]

to:

@]

Changed line 308 from:

=xml [=

to:

[@

Changed line 364 from:

=]

to:

@]

July 20, 2009, at 07:59 PM by anca_vamanu -

Changed lines 201-364 from:

=]

to:

=]

!Scenario Examples

!! Prepaid
This scenario can be used by a company for prepaid users to announce them at the beginning of the call what their credit is and at the end of the call what their remaining credit is.

What must happen at session level is:

# the caller is connected to a media server
# the caller is connected to the callee
# if the callee hangs up the phone before the caller, the caller is connected to a media server (the same or other).

The scenario document that describes this service is the one printed bellow:

=xml [=
<?xml version="1.0"?>
<scenario id="prepaid" name="MS start and end" param="2" type="script">
<init>
<bridge>
<server>
<id>server1</id>
</server>
<client>
<id>client1</id>
<type>message</type>
<destination>
<value type="param">1</value>
</destination>
</client>
</bridge>
<state>1</state>
</init>
<rules>
<request>
<bye>
<rule id="1">
<condition>
<state>1</state>
<sender>
<type>client</type>
<id>client1</id>
</sender>
</condition>
<action>
<send_reply>
<code>200</code>
<reason>OK</reason>
</send_reply>
<delete_entity/>
<bridge>
<client>
<id>server1</id>
</client>
<client>
<id>client2</id>
<destination>
<value type="initial">server1</value>
</destination>
</client>
</bridge>
<state>2</state>
</action>
</rule>

<rule id="2">
<condition>
<state>2</state>
<sender>
<type>client</type>
<id>client2</id>
</sender>
</condition>

<action>
<send_reply>
<code>200</code>
<reason>OK</reason>
</send_reply>
<delete_entity/>
<bridge>
<client>
<id>server1</id>
</client>
<client>
<id>client3</id>
<destination>
<value type="param">2</value>
</destination>
</client>
</bridge>
<state>3</state>
</action>
</rule>
</bye>
</request>
</rules>
</scenario>
=]

!! Marketing
The last test case is called �Marketing�, because it suits very well to the requirements of a marketing campaign through phone. The company might choose a list of potential costumers to call and announce about a new product/offer/discount. The message will be a recorded one, but the costumer will also be offered the possibility to talk to a human operator. If the costumer does not hung up the phone before the recorded message ends, it will be connected to a human operator. This is also a good means to filter the interested costumers and make the process more efficient with less resources used.

The OpenSIPS B2BUA must connect two end points, start the call from the middle. It is different from the other examples, since the call is initiated by the B2BUA and it is triggered by a MI command.

The scenario document that describes this service is:

=xml [=
<?xml version="1.0"?>
<scenary id="marketing" name="MS start conditional" param="3" type="extern">
<init>
<bridge>
<client>
<id>client1</id>
<destination>
<value type="param">1</value>
</destination>
</client>
<client>
<id>client2</id>
<destination>
<value type="param">2</value>
</destination>
</client>
</bridge>
<state>1</state>
</init>

<rules>
<request>
<bye>
<rule id="1">
<condition>
<state>1</state>
<sender>
<type>client</type>
<id>client2</id>
</sender>
</condition>
<action>
<send_reply>
<code>200</code>
<reason>OK</reason>
</send_reply>
<delete_entity/>
<bridge>
<client>
<id>client1</id>
</client>
<client>
<id>client3</id>
<destination>
<value type="param">3</value>
</destination>
</client>
</bridge>
<state>2</state>
</action>
</rule>
</bye>
</request>
</rules>
</scenario>
=]

July 20, 2009, at 07:55 PM by anca_vamanu -

Added lines 1-2:

The OpenSIPS B2BUA services have to be defined in scenario documents.

Added lines 178-201:

Bellow is an action example:

=xml [=
<action>
� � <send_reply>
� � � <code>200</code>
� � � <reason>OK</reason>
� � </send_reply>
� � <delete_entity/>
� � <bridge>
� � � <client>
� � � � <id>server1</id>
� � � </client>
� � � <client>
� � � � <id>client2</id>
� � � � <destination>
� � � � � <value type="initial">server1</value>
� � � � </destination>
� � � </client>
� � </bridge>
� � <state>2</state>
</action>
=]

July 20, 2009, at 07:51 PM by anca_vamanu -

Changed lines 118-175 from:

to:

=xml [=
<rules>
� <request>
� � <bye>
� � � <rule id= �1�>
...
� � � </rule>
� � � <rule id= �2�>
...
� � � </rule>
� � </bye>
� </request>
</rules>

=]

!!!! Rules condition part
The extra conditions that can be defined for a rule filter the scenario state and the direction of the message.

A condition will be matched if the scenario instantiation is in the same state as the state specified in the condition.

The direction of a message is specified with a '''sender''' node. The sender can be a certain entity specified with a type and an id, or a entity category, being sufficient to specify only the type.

=xml [=
<condition>
� �<state>1</state>
� �<sender>
� � � <type>client</type>
� � � <id>client1</id>
� �</sender>
</condition>
=]

!!!! Rules action part
In this first version there are four possible actions, with the possibility to extend them in the future. The actions are described in the table bellow.

||border=1
||'''Node name'''||'''Description'''||'''Example'''||
||send_reply||This node tells the B2BUA to send a reply to the sender of the current message. A code and reason sub node must be defined.||[@
<send_reply>
<code>200</code>
<reason>OK</reason>
</send_reply> @]||
||delete_entity||The delete_entity node specifies to the B2B Logic that the current entity which has received the message can be deleted.||<delete_entity/>||
||bridge||A bridge action means putting two end points in contact. The syntax is the same as the on for the bridge node in the init part. The only difference here is that the entities can be also existing ones. If a new entity is defined a destination node must be present.||[@
<bridge>
<client>
<id>client1</id>
</client>
<client>
<id>client3</id>
<destination>
<value type="param">
3</value>
</destination>
</client>
</bridge> @]||
||state||Specifies the state the scenario instantiation will enter after the action will be executed.||<state>2</state>||

July 20, 2009, at 07:43 PM by anca_vamanu -

Changed lines 63-64 from:

||'''Script scenario'''||'''Extern Scenario||
||<init>

to:

||'''Script scenario'''||'''Extern Scenario'''||
||[@<init>

Changed line 84 from:

</init><init>

to:

</init> @]||[@ <init>

Changed lines 104-107 from:

</init>
||
||

to:

</init> @]||

!!! Rules section
The rules have two parts:

* condition
* action

The condition part decides weather a rule should be applied for the current event. The events are represented by the receipt of a SIP request or SIP reply. The action part may define a request or reply to be sent out.

In the scenario document, the rules node has two children, requests and replies, separating the two types of events. Then both replies and requests have children with names of the possible requests inside dialog: 'invite', 'ack', 'bye' and for each more rules can be defined.

July 20, 2009, at 07:38 PM by anca_vamanu -

Changed lines 12-13 from:

to:

=xml [=
<scenario id="prepaid" name="MS start and end" param="2"type="script">
=]

Changed line 19 from:

* '''id''' � the identifier for the scenario. It will be provided to the logic when desiring to instantiate the scenario.

to:

* '''id �''' the identifier for the scenario. It will be provided to the logic when desiring to instantiate the scenario.

Changed line 29 from:

!!! Init section

to:

!!! Init section

Added lines 42-108:

=xml [=
<destination>
<value type="_value_type_">_value_</value>
</destination>
=]

|| border=1
|| Value source || Value type || Example ||
|| Inline URI || "uri" ||<destination><value type="uri">sip:ms@opensips.org</value></destination> ||
|| Parameter.The value node content is a number and represents the number of the parameter.||"param"||<destination><value type="param">1</value></destination>||
||Initial destination.Used when the bridging is based on a received message. The destination will be that from the message.||"initial"||<destination><value type="initial"></value></destination>||

The client entity can also have a '''type''' subnode. The only defined value for this node is ''''message''''. If type node with message value is present, it means that the client will be created using the info from received SIP message: the body, the caller URI, some SIP headers(Accept, Supported, Content-Type). Defining this node does not mean that the destination will be taken from this message and still a destination node must be defined.

In addition to the bridging node, you can also define a state node. The meaning of states in the b2b scenario is that of labels in the evolution of the scenario that can be used as conditions when defining rules. A '''state '''node in the '''init''' node specifies the state that the scenario instantiation will enter after the init part will be executed.

Below there are two examples of scenario init parts, one that creates entities based on a received message and in which the dialog is initiated by the b2bua that puts two entities in contact.

||border=1
||'''Script scenario'''||'''Extern Scenario||
||<init>
<bridge>

<server>
<id>server1</id>
</server>

<client>
<id>client1</id>
<type>message</type>
<destination>
<value type="param">1</value>
</destination>
</client>

</bridge>

<state>1</state>
</init><init>
<bridge>
<client>
<id>client1</id>
<destination>
<value type="param">1</value>
</destination>
</client>

<client>
<id>client2</id>

<destination>
<value type="param">2</value>
</destination>
</client>

</bridge>

<state>1</state>
</init>
||
||

July 20, 2009, at 05:59 PM by anca_vamanu -

Added lines 1-40:

! Scenario format
The scenarios are defined as XML documents because of their adaptability and because they are easy to understand and write.

A scenario is a predefined behavior that will be interpreted by the B2B Logic. The decision when the the scenario will be applied must be taken by the server administrator in the configuration file or triggered by an extern application.

The scenario is not rigid, but configurable through some parameters that will have to be provided to the B2B logic when requesting the instantiation of a certain scenario.

!! Scenario root
The '''root''' element has the tag 'scenario'.

It has three parameters:

* '''id''' � the identifier for the scenario. It will be provided to the logic when desiring to instantiate the scenario.
* '''name''' � a more explicit name. It has meaning only for the reader, with no importance for the B2BUA.
* '''param''' � the number of parameters the scenario requires.
* '''type''' � the type of the scenario. It can be ''script'' or ''extern.'' This parameter as the name parameter is not meaningful to the B2BUA but to the reader.

A B2B scenario document has two parts:

* a '''init''' section
* a '''rules''' section

!!! Init section
The '''init''' section provides indications about the entities that must be created at the beginning of the scenario. The '''init''' node has as a subnode a '''bridging''' node meaning that the entities created there will eventually be connected in a media session.

There can be two types of entities:

* '''server entity''' � for the first transaction the entity will behave as a UAS. This can be created only if there is a INVITE message that the entity will have to deal with. Server entities can appear only in scrip scenarios.
* '''client entity''' - a entity that has to start a dialog and send an initial message to a SIP endpoint.

Some parameters must be defined for the entities. Both server and client entities must be given an '''id''' that will be used to identify the entity later in the script. For the server entity no other parameters need to be defined.

For the client entities it is compulsory to define the destination where the messages will be sent. For this a '''destination''' sub node must be defined. The syntax of the destination node is:

The destination value can be provided in more ways

Resources.B2buaTutorial History