Resources.B2buaTutorial HistoryShow minor edits - Show changes to markup April 24, 2013, at 06:52 PM
by
- Changed lines 1-361 from:
Resources -> Documentation -> Tutorials-> B2BUABack-to-Back User Agentwritten by Anca Vamanu (:toc Table of Content:) OverviewOpenSIPS 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:
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 EntityThe name represents in fact the type if transaction entity that is created at the beginning. So there will be a
Scenario InstantiationThe 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 exteriorAs 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 servicesThere are two ways to trigger a B2B service.
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
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")
Loading scenariosThe 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")
Scenario formatThe 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 rootThe root element has the tag 'scenario'.
<scenario id="prepaid" name="MS start and end" param="2" type="script">
It has three parameters:
A B2B scenario document has two parts:
Init sectionThe 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:
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
<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.
Rules sectionThe rules have two parts:
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>
Rules condition partThe 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>
Rules action partIn 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.
Bellow is an action example:
<action>
Scenario ExamplesTopology HidingNo 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 SchemaHere is the theoretical expected message trace: http://www.opensips.org/images/top_hiding_schema.jpeg PrepaidThis 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:
In B2BUA terms, this is a script scenario that can be instantiating by specifying the id prepaid. It requires 2 parameters:
Scenario SchemaTo 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 DocumentThe full scenario document is printed bellow: <?xml version="1.0"?>
MarketingThe 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
Scenario SchemaBelow is the theoretical message flow that should occur for this functionality to be achieved. http://www.opensips.org/images/marketing.jpeg Scenario DocumentThe scenario document that describes this service is: <?xml version="1.0"?>
REFER ScenarioThe 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 DocumentThe scenario document that describes this service is: <?xml version="1.0"?>
Configuration fileYou 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:
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 fileThere are some requirements for a configuration file that enables the B2BUA services.
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)
ExampleYou 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 routesSpecial B2B routeThe 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")
Failure route not available for B2BIt 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:) April 27, 2011, at 01:48 PM
by
- 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 01:42 PM
by
- Deleted lines 309-315:
The pictures below show the script interaction with the b2b requests:
http://opensips.org/images/b2b_route_init.jpg
http://opensips.org/images/b2b_route_seq.jpg April 21, 2011, at 01:22 PM
by
- 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:
http://opensips.org/images/b2b_route_init.jpg
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:
Writing the configuration fileAdded line 343:
April 03, 2011, at 02:29 PM
by
- Changed line 171 from:
The condition part decides weather a rule should be applied for the current event. The events are represented by the receipt of a SIP request or SIP reply. The action part may define a request or reply to be sent out. to:
The condition part decides whether a rule should be applied for the current event. The events are represented by the receipt of a SIP request or SIP reply. The action part may define a request or reply to be sent out. February 11, 2011, at 03:41 PM
by
- Added line 5:
written by Anca Vamanu January 03, 2011, at 03:28 PM
by
- 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 02:59 PM
by
- Added lines 281-292:
REFER ScenarioThe 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 DocumentThe scenario document that describes this service is: <?xml version="1.0"?>
November 06, 2009, at 01:54 PM
by
- Added line 145:
November 06, 2009, at 01:42 PM
by
- Added lines 206-207:
October 28, 2009, at 10:44 AM
by
- Added lines 267-272:
Scenario SchemaBelow is the theoretical message flow that should occur for this functionality to be achieved. http://www.opensips.org/images/marketing.jpeg Scenario DocumentOctober 28, 2009, at 10:38 AM
by
- 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 HidingNo 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 SchemaHere is the theoretical expected message trace: http://www.opensips.org/images/top_hiding_schema.jpeg Changed lines 243-244 from:
to:
Scenario SchemaTo 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 DocumentOctober 27, 2009, at 10:32 AM
by
- Changed line 254 from:
<?xml version="1.0"?> to:
<?xml version="1.0"?> September 25, 2009, at 01:14 PM
by
- Added lines 287-292:
modparam("b2b_entities", "script_req_route", "b2b_request")
September 25, 2009, at 01:10 PM
by
- Changed lines 290-292 from:
It is impossible to have a t_on_failure() mechanism (which is transaction specific) on a B2BUA scenario (where you have multiple dialogs, with multiple transactions) - for complex scenarios, with multiple dialogs, you cannot say for which transaction to trigger the failure route for.....the "topo hiding" scenario is a very simple B2BUA scenario, but you cannot have a general "on_failure" concept for all b2bua scenarios. How I see this solved, is very simple: consider that b2bua is a separate instance (logically speaking) which selects types/classes of destinations. A proxy instance will responsible for routing inside the class of destinations. to:
It is impossible to have a t_on_failure() mechanism (which is transaction specific) on a B2BUA scenario (where you have multiple dialogs, with multiple transactions) - for complex scenarios, with multiple dialogs, you cannot say for which transaction to trigger the failure route for. The "topo hiding" scenario is a very simple B2BUA scenario, but you cannot have a general "on_failure" concept for all b2bua scenarios. A solution is to consider that b2bua is a separate instance (logically speaking) which selects types/classes of destinations. A proxy instance will responsible for routing inside the class of destinations. September 25, 2009, at 01:08 PM
by
- Changed lines 259-260 from:
Configuration file exampleto:
Configuration fileChanged 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:
ExampleYou 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 routesSpecial B2B routeThe 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 B2BIt is impossible to have a t_on_failure() mechanism (which is transaction specific) on a B2BUA scenario (where you have multiple dialogs, with multiple transactions) - for complex scenarios, with multiple dialogs, you cannot say for which transaction to trigger the failure route for.....the "topo hiding" scenario is a very simple B2BUA scenario, but you cannot have a general "on_failure" concept for all b2bua scenarios. How I see this solved, is very simple: consider that b2bua is a separate instance (logically speaking) which selects types/classes of destinations. A proxy instance will responsible for routing inside the class of destinations. For ex: in a scenario we can sent in the first place the call to Media Server for some announcement and later to PSTN GW. In a first step, the b2bua scenario will sent to proxy the call with RURI pointing to "a class" of media servers - the proxy will select the proper media server and do the failover between the media servers, totally transparent for the b2bua. In a similar way, on the second step, the b2bua scenario will indicate to proxy that it wants to have the call to be sent to PSTN GW (as type of destination) - the proxy will do lcr, drouting, failover between the GW. July 31, 2009, at 12:08 PM
by
- Changed lines 158-160 from:
to:
Changed line 204 from:
to:
July 31, 2009, at 11:39 AM
by
- Deleted lines 6-13:
July 31, 2009, at 11:29 AM
by
- Changed lines 5-6 from:
(:toc-float Table of Content:) to:
(:toc Table of Content:) Changed lines 17-18 from:
1. Overviewto:
OverviewChanged lines 46-47 from:
2. Initiating B2B servicesto:
Initiating B2B servicesChanged lines 86-87 from:
3. Loading scenariosto:
Loading scenariosChanged line 97 from:
4. Scenario formatto:
Scenario formatChanged lines 225-226 from:
5. Scenario Examplesto:
Scenario ExamplesChanged line 267 from:
6. Configuration file exampleto:
Configuration file exampleJuly 31, 2009, at 11:27 AM
by
- Added line 5:
(:toc-float Table of Content:) July 23, 2009, at 11:56 AM
by
- Added line 24:
Changed line 192 from:
[ to:
July 23, 2009, at 11:55 AM
by
- Changed lines 20-21 from:
to:
July 23, 2009, at 11:50 AM
by
- 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 servicesto:
2. Initiating B2B servicesChanged lines 83-84 from:
2. Loading scenariosto:
3. Loading scenariosChanged line 94 from:
3. Scenario formatto:
4. Scenario formatChanged lines 222-223 from:
4. Scenario Examplesto:
5. Scenario ExamplesChanged line 264 from:
5. Configuration file exampleto:
6. Configuration file exampleJuly 23, 2009, at 11:37 AM
by
- Added lines 6-16:
1. OverviewChanged 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 11:28 AM
by
- 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 EntityChanged 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:
Changed lines 25-26 from:
A scenario instantiation is an application of a scenario that is currently in process. The b2b_logic module might be told to initialize a scenario in two ways: from the script, by calling a function that the module exports when an initial request is received, or by sending an external command. When receiving one of this two events, the b2b_logic module will create a record(corresponding to the red small boxes in the drawing) with the information for that scenario instantiation. Also at this moment, the b2b_logic module tells the b2b_entities module to create the entities(server and/or clients) that it requires. The record mainly stores a relation to the scenario document that it must follow, the state of the scenario application and the identifiers for the entities in b2b_entities module. to:
A scenario instantiation is an application of a scenario that is currently in progress. The b2b_logic module might be told to initialize a scenario in two ways: from the script, by calling a function that the module exports when an initial request is received, or by sending an external command. When receiving one of this two events, the b2b_logic module will create a record(corresponding to the red small boxes in the drawing) with the information for that scenario instantiation. Also at this moment, the b2b_logic module tells the b2b_entities module to create the entities(server and/or clients) that it requires. The record mainly stores a relation to the scenario document that it must follow, the state of the scenario application and the identifiers for the entities in b2b_entities module. Changed line 28 from:
As can be seen in the picture, the b2b_entities module uses directly the functions provided by the tm module for sending requests and replies and for receiving replies. External commands will be received through the Management Interface from core which at its turn hides the transportation means that is used for sending the command. to:
As can be seen in the picture, the b2b_entities module is the bottom half part of B2BUA and it deals with the actual network message exchange. To achieve this it uses directly the functions provided by the tm module for sending requests and replies and for receiving replies. Also the tm module announce it when a reply for a request that it has sent is received. For requests inside dialog, the b2b_entities module registers a prescript function that catches this requests. In the current implementation, this requests don't go into the script because the prescript function returns '0'. As mentioned earlier, when receiving a reply or request that is matched to a known dialog, the b2b_entities module does no further action but notifies the b2b_logic module about this event. The b2b_logic module will then decide what July 22, 2009, at 07:15 PM
by
- Changed line 6 from:
OpenSIPS has many features but in the way it behaves when a media session is established, it is not more than a proxy, meaning that it only takes the messages from one side and pass them on the other side. However, this has proven not to be enough as it is necessary to support services which require the server to be aware of the state of the sessions, monitor and control them. A Back-to-Back User Agent is exactly this, a entity in the SIP network which has the ability to control or start media sessions. The name comes from the behavior, since in fact what is required is for the B2BUA to stand in the middle and establish two dialogs with both end points that will eventually exchange media. to:
OpenSIPS has many features but in the way it behaves when a media session is established, it is not more than a proxy, meaning that it only takes the messages from one side and pass them on the other side. However, this has proven not to be enough as to provide certain services requires for the server to be aware of the state of the sessions, monitor and control them. A Back-to-Back User Agent is exactly this, a entity in the SIP network which has the ability to control or start media sessions. The name comes from the behavior, since in fact what is required is for the B2BUA to stand in the middle and establish two dialogs with both end points that will eventually exchange media. July 22, 2009, at 07:14 PM
by
- 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 InstantiationA 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 exteriorAs can be seen in the picture, the b2b_entities module uses directly the functions provided by the tm module for sending requests and replies and for receiving replies. External commands will be received through the Management Interface from core which at its turn hides the transportation means that is used for sending the command. July 22, 2009, at 07:10 PM
by
- Added lines 12-14:
The picture bellow shows the architecture of the B2BUA implementation. http://www.opensips.org/images/B2BUA_architecture.jpg July 22, 2009, at 07:08 PM
by
- Added lines 5-6:
OpenSIPS has many features but in the way it behaves when a media session is established, it is not more than a proxy, meaning that it only takes the messages from one side and pass them on the other side. However, this has proven not to be enough as it is necessary to support services which require the server to be aware of the state of the sessions, monitor and control them. A Back-to-Back User Agent is exactly this, a entity in the SIP network which has the ability to control or start media sessions. The name comes from the behavior, since in fact what is required is for the B2BUA to stand in the middle and establish two dialogs with both end points that will eventually exchange media. July 22, 2009, at 05:24 PM
by
- Added line 46:
_empty_line_ July 22, 2009, at 05:17 PM
by
- Changed line 24 from:
1. Instantiating B2B servicesto:
1. Initiating B2B servicesJuly 22, 2009, at 05:12 PM
by
- Added line 85:
Changed line 123 from:
to:
Changed lines 126-128 from:
to:
Changed line 157 from:
[<<] to:
Changed line 171 from:
[<<] to:
[ Deleted line 172:
[<<] Changed line 182 from:
[<<] to:
Changed line 184 from:
[<<] to:
Changed line 193 from:
[<<] to:
Deleted line 194:
[<<] July 22, 2009, at 05:08 PM
by
- Added line 85:
Ex: Scenario root node example Added lines 116-117:
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.
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 04:56 PM
by
- Changed line 245 from:
modparam("tm", "pass_provisional_replies", 1) to:
modparam("tm", "pass_provisional_replies", 1) July 22, 2009, at 04:51 PM
by
- Changed lines 40-48 from:
[<<] marketing [<<] sip:bob@opensips.org [<<] sip:322@opensips.org:5070 [<<] to:
:b2b_trigger_scenario:fifo_reply 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") 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") July 22, 2009, at 04:43 PM
by
- Changed lines 41-44 from:
to:
[<<] marketing [<<] sip:bob@opensips.org [<<] sip:322@opensips.org:5070 [<<] July 22, 2009, at 04:41 PM
by
- 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:
July 22, 2009, at 04:40 PM
by
- Changed line 40 from:
to:
July 22, 2009, at 04:39 PM
by
- 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 04:36 PM
by
- Changed line 88 from:
to:
Changed lines 90-91 from:
to:
July 22, 2009, at 04:35 PM
by
- 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:
to:
July 22, 2009, at 03:39 PM
by
- 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 03:28 PM
by
- 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 03:24 PM
by
- Added lines 220-223:
July 22, 2009, at 03:20 PM
by
- Changed lines 65-66 from:
Loading scenariosto:
2. Loading scenariosChanged line 77 from:
Scenario formatto:
3. Scenario formatChanged lines 174-175 from:
Scenario Examplesto:
4. Scenario ExamplesChanged line 210 from:
Configuration file exampleto:
5. Configuration file exampleJuly 22, 2009, at 03:17 PM
by
- Added lines 208-219:
Configuration file exampleThere are some requirements for a configuration file that enables the B2BUA services.
July 22, 2009, at 03:00 PM
by
- Added lines 200-204:
The id which must be mentioned to start this service is 'marketing'. It requires 3 parameters
July 22, 2009, at 02:52 PM
by
- 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 full scenario document is printed bellow: July 22, 2009, at 01:24 PM
by
- Changed lines 22-24 from:
Instantiating B2B servicesto:
1. Instantiating B2B servicesJuly 22, 2009, at 01:18 PM
by
- Changed line 70 from:
modparam("b2b_logic", "extern_scenario", "//usr/local/opensips/etc/b2bua/scenario_extern.xml")@] to:
modparam("b2b_logic", "extern_scenario", "/usr/local/opensips/etc/b2bua/scenario_extern.xml")@] July 22, 2009, at 01:18 PM
by
- Changed lines 69-70 from:
modparam("b2b_logic", "script_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_script.xml") modparam("b2b_logic", "extern_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_extern.xml") to:
modparam("b2b_logic", "script_scenario", "/usr/local/opensips/etc/b2bua/scenario_script.xml") modparam("b2b_logic", "extern_scenario", "//usr/local/opensips/etc/b2bua/scenario_extern.xml") July 22, 2009, at 01:17 PM
by
- Changed line 52 from:
Ex: to:
Ex: Calling top hiding service Changed lines 54-56 from:
to:
if(is_method("INVITE") && src_ip=="10.10.10.10") b2b_init_request("top hiding"); July 22, 2009, at 01:14 PM
by
- Changed lines 67-68 from:
modparam("b2b_logic", "script_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_script.xml") modparam("b2b_logic", "extern_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_extern.xml") to:
modparam("b2b_logic", "script_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_script.xml") modparam("b2b_logic", "extern_scenario", "/home/anca/work/opensips/modules/b2b_logic/scenario_extern.xml") July 22, 2009, at 01:14 PM
by
- 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:
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 12:54 PM
by
- Changed lines 32-39 from:
Ex: Fifo MI command
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:
July 22, 2009, at 12:35 PM
by
- Changed lines 33-34 from:
to:
Changed lines 38-39 from:
sip:alice@opensips.org to:
sip:alice@opensips.org|| July 22, 2009, at 12:34 PM
by
- Changed line 33 from:
---\\ to:
Changed line 39 from:
--- to:
July 22, 2009, at 12:34 PM
by
- Changed lines 32-33 from:
Ex: to:
Ex: Fifo MI command\\ July 22, 2009, at 12:33 PM
by
- Changed lines 32-35 from:
Ex: Fifo MI command --- to:
Ex: July 22, 2009, at 12:33 PM
by
- 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 July 22, 2009, at 12:31 PM
by
- Added line 31:
Added line 33:
Deleted line 34:
[@ Changed lines 36-40 from:
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 12:29 PM
by
- 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 11:30 AM
by
- Added lines 28-31:
The first parameter is the name of the scenario to be instantiated. So it is the job of the script writer to decide when a certain scenario should be applied . The next arguments are parameters needed by the scenario. As it shall be seen later, a scenario can require some values to be given as parameters in contrast to hard coding them, making the scenario configurable. The MI command has the name b2b_trigger_scenario and as the script function it takes maximum 6 arguments, the first one being the name of the scenario. July 22, 2009, at 11:27 AM
by
- 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 11:26 AM
by
- 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 scenarioto:
Instantiating B2B servicesThere are two ways to trigger a B2B service.
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 11:09 AM
by
- 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 11:07 AM
by
- Changed lines 4-5 from:
Back-to-Back User Agentto:
Back-to-Back User AgentChanged lines 19-20 from:
Instantiating a scenarioto:
Instantiating a scenarioChanged line 22 from:
Scenario formatto:
Scenario formatChanged line 31 from:
Scenario rootto:
Scenario rootChanged lines 119-121 from:
Scenario ExamplesPrepaidto:
Scenario ExamplesPrepaidChanged line 133 from:
Marketingto:
MarketingJuly 22, 2009, at 11:01 AM
by
- 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 scenarioto:
Added line 118:
[#Scenario_examples] July 22, 2009, at 10:57 AM
by
- Changed line 6 from:
B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers building certain services on top of it. The services are defined in documents called scenarios. A certain scenario can be activated at the receipt of an initial request from the script or with an MI command. to:
B2BUA in OpenSIPS is an implementation of the behavior of a B2BUA as defined in RFC 3261 that offers the possibility to build certain services on top of it. The services are defined in documents called scenarios. A certain scenario can be activated at the receipt of an initial request from the script or with an MI command. July 22, 2009, at 10:56 AM
by
- Changed lines 2-13 from:
Back-to-Back User Agentto:
Back-to-Back User AgentB2BUA 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: July 21, 2009, at 06:22 PM
by
- Added lines 13-16:
Instantiating a scenarioJuly 21, 2009, at 06:07 PM
by - July 21, 2009, at 06:06 PM
by
- 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"?> 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"?> July 21, 2009, at 06:04 PM
by
- Changed line 96 from:
to:
July 21, 2009, at 06:03 PM
by
- Changed lines 86-95 from:
<condition> <state>1</state> <sender> <type>client</type> <id>client1</id> </sender> </condition> to:
<condition> Changed lines 93-111 from:
to:
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> July 21, 2009, at 05:59 PM
by
- Changed lines 76-91 from:
<rules> <request> <bye> <rule id= 1> ... </rule> <rule id= 2> ... </rule> </bye> </request> </rules> to:
<rules> July 21, 2009, at 05:57 PM
by
- Changed line 63 from:
to:
July 21, 2009, at 05:54 PM
by
- Changed lines 63-103 from:
to:
July 21, 2009, at 05:49 PM
by
- Changed line 50 from:
to:
July 21, 2009, at 05:49 PM
by
- Changed lines 50-52 from:
to:
July 21, 2009, at 05:35 PM
by
- Changed lines 45-50 from:
<destination> <value type="_value_type_">_value_</value> </destination> to:
<destination> July 21, 2009, at 05:34 PM
by
- 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 05:33 PM
by
- 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 12:51 PM
by
- Changed line 5 from:
The OpenSIPS B2BUA services have to be defined in scenario documents that have a certain strcture. to:
The OpenSIPS B2BUA services have to be defined in scenario documents that have a certain structure that will be described in this tutorial. Also at the end of the tutorial there are presented two examples of scenarios, one that interposes recorded messages before and after the actual call and one in which the B2BUA connects two parties in a call. July 21, 2009, at 12:49 PM
by
- Changed line 1 from:
Resources -> Documentation -> B2BUAto:
Resources -> Documentation -> Tutorials-> B2BUAJuly 21, 2009, at 12:47 PM
by
- Changed lines 1-2 from:
The OpenSIPS B2BUA services have to be defined in scenario documents. to:
Resources -> Documentation -> B2BUABack-to-Back User AgentThe OpenSIPS B2BUA services have to be defined in scenario documents that have a certain strcture. Changed line 10 from:
A scenario is a predefined behavior that will be interpreted by the B2B Logic. The decision when the the scenario will be applied must be taken by the server administrator in the configuration file or triggered by an extern application. to:
A scenario is a predefined behavior that will be interpreted by the B2B Logic. The decision when the the scenario will be applied must be taken by the server administrator in the configuration file or triggered by an extern application with an MI command. July 20, 2009, at 08:00 PM
by
- Changed line 216 from:
=xml [= to:
[@ Changed lines 299-300 from:
=] to:
@] Changed line 308 from:
=xml [= to:
[@ Changed line 364 from:
=] to:
@] July 20, 2009, at 07:59 PM
by
- Changed lines 201-364 from:
=] to:
=] Scenario ExamplesPrepaidThis scenario can be used by a company for prepaid users to announce them at the beginning of the call what their credit is and at the end of the call what their remaining credit is. What must happen at session level is:
The 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> MarketingThe 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 07:55 PM
by
- 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 07:51 PM
by
- Changed lines 118-175 from:
to:
<rules> <request> <bye> <rule id= 1> ... </rule> <rule id= 2> ... </rule> </bye> </request> </rules> Rules condition partThe 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 partIn 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.
July 20, 2009, at 07:43 PM
by
- Changed lines 63-64 from:
to:
Changed line 84 from:
</init><init> to:
</init> @]||[@ <init> Changed lines 104-107 from:
</init> to:
</init> @]|| Rules sectionThe rules have two parts:
The condition part decides weather a rule should be applied for the current event. The events are represented by the receipt of a SIP request or SIP reply. The action part may define a request or reply to be sent out. In the scenario document, the rules node has two children, requests and replies, separating the two types of events. Then both replies and requests have children with names of the possible requests inside dialog: 'invite', 'ack', 'bye' and for each more rules can be defined. July 20, 2009, at 07:38 PM
by
- Changed lines 12-13 from:
to:
<scenario id="prepaid" name="MS start and end" param="2"type="script"> Changed line 19 from:
to:
Changed line 29 from:
Init sectionto:
Init sectionAdded lines 42-108:
<destination> <value type="_value_type_">_value_</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.
<bridge> <server> <id>server1</id> </server> <client> <id>client1</id> <type>message</type> <destination> <value type="param">1</value> </destination> </client> </bridge> <state>1</state> </init><init> <bridge> <client> <id>client1</id> <destination> <value type="param">1</value> </destination> </client> <client> <id>client2</id> <destination> <value type="param">2</value> </destination> </client> </bridge> <state>1</state> </init> July 20, 2009, at 05:59 PM
by
- Added lines 1-40:
Scenario formatThe 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 rootThe root element has the tag 'scenario'. It has three parameters:
A B2B scenario document has two parts:
Init sectionThe 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:
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 |