#527 B2B - Second Call Transfer doesn't work

[Duane Larson]

I think this might be a bug or else I wouldn't post. The version I am running is
$Id: main.c 8772 2012-03-08 11:16:13Z bogdan_ianc

Here are the details
http://opensips-open-sip-server.1449251.n2.nabble.com/B2BUA-Multiple-Transfer-Refer-issue-td7564757.html

I was doing some special stuff on the OpenSIPS B2BUA server in order to get Call Park with Asterisk to work, but just to be sure I removed that stuff and I still see the same issue.

[Anca Vamanu]

Hi Duane,

First the logs seemed strange, but then I figured out what is wrong.
The reason why the Refer scenario is executed differently the second time is that when specifying the new client entity to create with the destination the URI in Refer-To header, the same id is used 'client2': http://www.opensips.org/Resources/B2buaTutorial#toc15

So actually it does not create a new client entity, but tries to bridge again the existing ones.

The fix in the code is to permit not defining a client id, because in this case it is not needed, as it is never used ( never is an entity referred by the id). I will try to implement this fix in the next period.

The quick hack for this is to define sort of a loop of Refer rules ( I remember I saw this at someone some time ago).
It would look like this:
<?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>
<state>1</state>
</init>

<rules>
<request>
<refer>

<rule id="1">
<condition>
<state>1</state>
</condition>
<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>
<state>2</state>
</rule>

<rule id="2">
<condition>
<state>2</state>
</condition>
<action>
<send_reply>
<code>202</code>
<reason>Accepted</reason>
</send_reply>
<end_dialog_leg/>
<bridge>
<client>
<peer/>
</client>
<client>
<id>client3</id>
<destination>
<value type="header">Refer-To</value>
</destination>
</client>
</bridge>
</action>
<state>1</state>
</rule>

</refer>
</request>
</rules>
</scenario>

Regards,
Anca

[Duane Larson]

This does allow for one extra transfer after the first initial transfer, but after a third transfer it fails again. Hopefully this can hold me over until a fix is place in the next period.

I don't think too many people would run into this. I wouldn't have noticed this unless I was implementing an Auto Attendant with Asterisk and it had to transfer the call to an Operator who would then need to transfer the call to whoever. Lets hope that whoever doesn't also want to transfer the call :).

Thanks for looking at this.

[Anca Vamanu]

Hi Duane,

When I started working on the patch, I observed that actually there is something implemented for this case.
It seems that if you put the <new> node, your problems with reusage of id will be solved. I have not tested this now, and I am not 100% sure that it still works, but you could give it a try.
The scenario part will look like this:

<client>
<id>client2</id>
<new/>
<destination>
<value type="header">Refer-To</value>
</destination>

Regards,
Anca

[Duane Larson]

Genius! The "<new/>" node does still work.

I was able to do about 4 transfers and then stopped after that since 4 transfers is pretty damn sweet. I will update my post in the mailing list. Who could I talk with about getting the B2BUA tutorial updated with the <new/> node?

[Anca Vamanu]

Great!
You could have updated the tutorial yourself actually since it's an wiki :). But now I will do it.

Regards,
Anca

[Anca Vamanu]

Hi Duane,

I made a small commit now not to require a <new/> node anymore if a <destination> node is present. You can try this out also if you like.

Regards,
Anca

[Duane Larson]

Just tested with new trunk version of the code and it does work without the <new/>. Awesome.

One thing though. I was playing around with the following modparam
modparam("b2b_logic", "b2bl_key_avp", "$avp(99)")
After I downloaded the lastest trunk version I got the following error when trying to restart opensips

Jun 15 21:43:13 [9075] ERROR:core:set_mod_param_regex: parameter <b2bl_key_avp> not found in module <b2b_logic>
Jun 15 21:43:13 [9075] CRITICAL:core:yyerror: parse error in config file /usr/local/etc/opensips/opensips.cfg, line 99, column 20-21: Parameter <b2bl_key_avp> not found in module <b2b_logic> - can't set
Jun 15 21:43:13 [9075] ERROR:core:main: bad config file (1 errors)

Just wanted to let you know. I'm not really using it since it didn't seem to solve another problem I was having.

[Bogdan-Andrei Iancu]

Hi Duan,

in 1.8 and trunk, that parameter (the b2bl_key_avp) was removed as some changes in the b2b_logic versus b2b_entities (by Ovidiu Sas) made impossible the presence of this parameter.

Is it something critical to you ?

Regards,
Bogdan

[Nobody/Anonymous]

No not critical. Turns out I didn't need it.

So it's not a problem.

[Nobody/Anonymous]

On a second thought, maybe removing it completely wasn't a good idea.
It is useful to have it _only_ after calling b2b_init_request. It can be used after for doing a bridge request from the script:
http://www.opensips.org/html/docs/modules/1.8.x/b2b_logic.html#id248973

The plan is to be restored on the next release with full functionality (just like in 1.7).

Regards,
Ovidiu Sas

[Bogdan-Andrei Iancu]

Ovidiu, please open then a new ticket (bug or feature) for re-buidling the variable.
I will close this ticket.