Resources.B2buaTutorial History

Hide minor edits - Show changes to markup

April 24, 2013, at 05:52 PM by 109.99.235.212 -
Changed lines 1-361 from:

Resources -> Documentation -> Tutorials-> B2BUA


Back-to-Back User Agent

written by Anca Vamanu

(:toc Table of Content:)

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

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)

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).

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.

Ex: Fifo MI command

: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.

Ex: Calling top hiding service

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


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

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.

Ex: Loading B2BUA scenarios

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")


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'.
Ex: Scenario root node example

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


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
Ex: Scenario destination node example

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



Table: Scenario destination node structure

Value sourceValue typeExample
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>
Header body.Take the URI from the body of a header. The first header with that name will be used."header"
<destination>
   
<value type="header">Refer-To</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.


Table: Scenario init node examples

Script scenarioExtern Scenario
<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>
<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>

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.

Ex: Scenario rules node structure

<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.


Ex: Scenario condition node

<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.


Table: Scenario rules node structure

Node nameDescriptionExample
send_replyThis 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_entityThe delete_entity node specifies to the B2B Logic that the current entity which has received the message can be deleted.
<delete_entity/>
bridgeA 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).
<bridge>
 
<client>
   
<id>client1</id>
 
</client>
 
<client>
   
<id>client3</id>
   
<destination>
     
<value type="param">
     3
</value>
 
</destination>
 
</client>
 
<lifetime>79800</lifetime>
</bridge>
stateSpecifies the state the scenario instantiation will enter after the action will be executed.
<state>2</state>
end_dialog_legThis 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.
<end_dialog_leg/>

Bellow is an action example:
Ex: Scenario action node

<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>


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:

  1. the caller is connected to a media server
  2. the caller is connected to the callee
  3. 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:

<?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 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:

<?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>


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:

<?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>


Configuration file

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.

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:

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


Example

You can find 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.

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");
}


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 08:09 PM by anca_vamanu - Description of the new node.
Changed line 208 from:
bridgeA 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).
<bridge>
 
<client>
   
<id>client1</id>
 
</client>
 
<client>
   
<id>client3</id>
   
<destination>
     
<value type="param">
     3
</value>
 
</destination>
 
</client>
 
<lifetime>79800</lifetime>
</bridge>
to:
bridgeA 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).
<bridge>
 
<client>
   
<id>client1</id>
 
</client>
 
<client>
   
<id>client3</id>
   
<destination>
     
<value type="param">
     3
</value>
 
</destination>
 
</client>
 
<lifetime>79800</lifetime>
</bridge>
April 27, 2011, at 12:48 PM by anca_vamanu -
Added lines 315-316:

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 12: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 12:22 PM by anca_vamanu -
Added lines 300-324:

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 01: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 02:41 PM by anca_vamanu -
Added line 5:

written by Anca Vamanu

January 03, 2011, at 02:28 PM by anca_vamanu -
Added lines 47-48:

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).

November 06, 2009, at 01: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:

<?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>


November 06, 2009, at 12: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"
<destination>
   
<value type="header">Refer-To</value>
</destination>
November 06, 2009, at 12:42 PM by anca_vamanu -
Added lines 206-207:
end_dialog_legThis 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.
<end_dialog_leg/>
October 28, 2009, at 09: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 09: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 09:32 AM by anca_vamanu -
Changed line 254 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:
<?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>
September 25, 2009, at 12:14 PM by anca_vamanu -
Added lines 287-292:
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");
}


September 25, 2009, at 12: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 12:08 PM by anca_vamanu -
Changed lines 259-260 from:

Configuration file example

to:

Configuration file

Changed lines 280-295 from:

You can find 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 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 11:08 AM by anca_vamanu -
Changed lines 158-160 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:
<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>
<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>
Changed line 204 from:
bridgeA 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:
bridgeA 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).
<bridge>
 
<client>
   
<id>client1</id>
 
</client>
 
<client>
   
<id>client3</id>
   
<destination>
     
<value type="param">
     3
</value>
 
</destination>
 
</client>
 
<lifetime>79800</lifetime>
</bridge>
July 31, 2009, at 10: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 10:27 AM by anca_vamanu -
Added line 5:

(:toc-float Table of Content:)

July 23, 2009, at 10:56 AM by anca_vamanu -
Added line 24:
Changed line 192 from:

[

to:


July 23, 2009, at 10: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 10: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 10:37 AM by anca_vamanu -
Added lines 6-16:
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:
to:
Deleted lines 48-49:
July 23, 2009, at 10: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 06: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 06: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 06: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 06: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 04:24 PM by anca_vamanu -
Added line 46:

_empty_line_

July 22, 2009, at 04:17 PM by anca_vamanu -
Changed line 24 from:

1. Instantiating B2B services

to:

1. Initiating B2B services

July 22, 2009, at 04:12 PM by anca_vamanu -
Added line 85:


Changed line 123 from:
to:


Changed lines 126-128 from:
Value sourceValue typeExample
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>
to:
Value sourceValue typeExample
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>
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 04:08 PM by anca_vamanu -
Added line 85:

Ex: Scenario root node example

Added lines 116-117:


Ex: Scenario destination node example

Changed line 123 from:
to:

Table: 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.


Table: Scenario init node examples

Added lines 155-156:

Ex: Scenario rules node structure [<<]

Added lines 170-172:

[<<] Ex: Scenario condition node [<<]

Added lines 182-184:

[<<] Table: Scenario rules node structure [<<]

Added lines 193-195:

[<<] Ex: Scenario action node [<<]

July 22, 2009, at 03:56 PM by anca_vamanu -
Changed line 245 from:

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

to:
modparam("tm", "pass_provisional_replies", 1)
July 22, 2009, at 03:51 PM by anca_vamanu -
Changed lines 40-48 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

Changed lines 55-58 from:
if(is_method("INVITE") && src_ip=="10.10.10.10")
   b2b_init_request("top hiding");
to:
if(is_method("INVITE") && src_ip=="10.10.10.10")
   b2b_init_request
("top hiding");
Changed lines 68-70 from:
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:
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 03: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 03:41 PM by anca_vamanu -
Changed lines 40-45 from:
:b2b_trigger_scenario:fifo_reply
marketing
sip:bob@opensips.org
sip:322@opensips.org:5070
sip:alice@opensips.org
to:
b2b_trigger_scenario
fifo_reply
marketing
sip:bob@opensips.org
sip:322@opensips.org:5070
sip:alice@opensips.org
July 22, 2009, at 03:40 PM by anca_vamanu -
Changed line 40 from:
to:
July 22, 2009, at 03:39 PM by anca_vamanu -
Changed line 40 from:
to:
Added line 118:
Changed lines 120-121 from:
to:


Added line 152:
Changed lines 154-155 from:
to:


Added line 165:
Changed lines 167-170 from:
to:


Added line 182:
Changed lines 184-187 from:
to:


Added line 209:
Changed lines 211-213 from:
to:


Added line 225:
Added lines 227-228:


July 22, 2009, at 03:36 PM by anca_vamanu -
Changed line 88 from:
to:
Changed lines 90-91 from:
to:


July 22, 2009, at 03: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 02: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:

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


July 22, 2009, at 02:28 PM by anca_vamanu -
Added line 224:

You can find 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 02: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 02: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 02:17 PM by anca_vamanu -
Added lines 208-219:

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 02: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 01: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 12:24 PM by anca_vamanu -
Changed lines 22-24 from:

Instantiating B2B services

to:

1. Instantiating B2B services

July 22, 2009, at 12: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 12: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 12:17 PM by anca_vamanu -
Changed line 52 from:

Ex:

to:

Ex: 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 12: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 12: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.

Ex: Loading B2BUA scenarios

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 11:54 AM by anca_vamanu -
Changed lines 32-39 from:

Ex: Fifo MI command
||border=1

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

Ex: Fifo MI command

: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:

b2b_init_request("top hiding");


July 22, 2009, at 11:35 AM by anca_vamanu -
Changed lines 33-34 from:
to:
Changed lines 38-39 from:

sip:alice@opensips.org
||

to:

sip:alice@opensips.org||

July 22, 2009, at 11:34 AM by anca_vamanu -
Changed line 33 from:

---\\

to:
Changed line 39 from:

---

to:
July 22, 2009, at 11:34 AM by anca_vamanu -
Changed lines 32-33 from:

Ex:
Fifo MI command\\

to:

Ex: Fifo MI command\\

July 22, 2009, at 11:33 AM by anca_vamanu -
Changed lines 32-35 from:

Ex:

Fifo MI command ---

to:

Ex:
Fifo MI command
---\\

July 22, 2009, at 11:33 AM by anca_vamanu -
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:

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

July 22, 2009, at 11:31 AM 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:

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

Deleted line 41:

@]

July 22, 2009, at 11:29 AM by anca_vamanu -
Changed lines 24-27 from:

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

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. 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. 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 10: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 10:27 AM by anca_vamanu -
Changed line 26 from:
int '''b2b_init_request'''(struct sip_msg* msg, str* scenario_name, str* param1, str* param2, str* param3, str* param4, str* param5);
to:
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 10:26 AM by anca_vamanu -
Added line 12:
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:

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

July 22, 2009, at 10:09 AM by anca_vamanu -
Changed line 18 from:

[#Initiating_B2B_services]

to:

Changed line 21 from:

[#Loading_scenarios]

to:

Changed line 118 from:

[#Scenario_examples]

to:

July 22, 2009, at 10: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 10:01 AM by anca_vamanu -
Changed lines 10-15 from:
to:
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 09:57 AM by anca_vamanu -
Changed line 12 from:
to:
July 22, 2009, at 09: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 09: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:

  1. Initiating B2B services?
  2. Loading scenarios?
  3. Configuration file example?
July 21, 2009, at 05:22 PM by anca_vamanu -
Added lines 13-16:

Instantiating a scenario

July 21, 2009, at 05:07 PM by anca_vamanu -
July 21, 2009, at 05: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:
<?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>
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:
<?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 21, 2009, at 05:04 PM by anca_vamanu -
Changed line 96 from:
stateSpecifies the state the scenario instantiation will enter after the action will be executed.<state>2</state>
to:
stateSpecifies the state the scenario instantiation will enter after the action will be executed.
<state>2</state>
July 21, 2009, at 05:03 PM by anca_vamanu -
Changed lines 86-95 from:
<condition>
   <state>1</state>
   <sender>
      <type>client</type>
      <id>client1</id>
   </sender>
</condition>
to:
<condition>
   
<state>1</state>
   
<sender>
     
<type>client</type>
     
<id>client1</id>
   
</sender>
</condition>
Changed lines 93-111 from:
send_replyThis 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_entityThe delete_entity node specifies to the B2B Logic that the current entity which has received the message can be deleted.<delete_entity/>
bridgeA 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_replyThis 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_entityThe delete_entity node specifies to the B2B Logic that the current entity which has received the message can be deleted.
<delete_entity/>
bridgeA 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>
Changed lines 99-120 from:
<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:
<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 21, 2009, at 04:59 PM by anca_vamanu -
Changed lines 76-91 from:
<rules>
  <request>
    <bye>
      <rule id= ”1”>
...
      </rule>
      <rule id= ”2”>
...
      </rule>
    </bye>
  </request>
</rules>

to:
<rules>
 
<request>
   
<bye>
     
<rule id=1>
        ...
     
</rule>
     
<rule id=2>
        ...
     
</rule>
   
</bye>
 
</request>
</rules>
July 21, 2009, at 04:57 PM by anca_vamanu -
Changed line 63 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>
[@ 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>
to:
<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 21, 2009, at 04: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:
<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>
[@ 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>
July 21, 2009, at 04:49 PM by anca_vamanu -
Changed line 50 from:
Inline URI"uri"
<destination>
   
<value type="uri">sip:ms@opensips.org</value>
</destination>
to:
Inline URI"uri"
<destination>
   
<value type="uri">sip:ms@opensips.org</value>
</destination>
July 21, 2009, at 04: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"
<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>
July 21, 2009, at 04:35 PM by anca_vamanu -
Changed lines 45-50 from:
<destination>
<value type="_value_type_">_value_</value>
</destination>
to:
<destination>
   
<value type="_value_type_">_value_</value>
</destination>
July 21, 2009, at 04:34 PM by anca_vamanu -
Changed line 17 from:
<scenario id="prepaid" name="MS start and end" param="2"type="script">
to:
<scenario id="prepaid" name="MS start and end" param="2" type="script">
July 21, 2009, at 04:33 PM by anca_vamanu -
Changed lines 17-20 from:
<scenario id="prepaid" name="MS start and end" param="2"type="script">
to:
<scenario id="prepaid" name="MS start and end" param="2"type="script">
July 21, 2009, at 11:51 AM 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 11:49 AM by anca_vamanu -
Changed line 1 from:

Resources -> Documentation -> B2BUA

to:

Resources -> Documentation -> Tutorials-> B2BUA

July 21, 2009, at 11:47 AM by anca_vamanu -
Changed lines 1-2 from:

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

to:

Resources -> 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 07: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 06: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:

  1. the caller is connected to a media server
  2. the caller is connected to the callee
  3. 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 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 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 06: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:

<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 06:51 PM by anca_vamanu -
Changed lines 118-175 from:
to:
<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.

<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.

Node nameDescriptionExample
send_replyThis 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_entityThe delete_entity node specifies to the B2B Logic that the current entity which has received the message can be deleted.<delete_entity/>
bridgeA 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> 
stateSpecifies the state the scenario instantiation will enter after the action will be executed.<state>2</state>
July 20, 2009, at 06:43 PM by anca_vamanu -
Changed lines 63-64 from:
Script scenario'''Extern Scenario
to:
Script scenarioExtern Scenario
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 06:38 PM by anca_vamanu -
Changed lines 12-13 from:
to:
<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:
<destination>
<value type="_value_type_">_value_</value>
</destination>
Value sourceValue typeExample
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.

Script scenario'''Extern Scenario
      <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 04: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


Page last modified on April 24, 2013, at 05:52 PM