[OpenSIPS-Devel] [ opensips-Bugs-3528675 ] B2B - Second Call Transfer doesn't work

SourceForge.net noreply at sourceforge.net
Fri May 25 20:26:47 CEST 2012


Bugs item #3528675, was opened at 2012-05-21 12:22
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3528675&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Duane Larson (duanelarson123)
Assigned to: Nobody/Anonymous (nobody)
Summary: B2B - Second Call Transfer doesn't work

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

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2012-05-25 11:26

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



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2012-05-24 00:52

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

Regards,
Anca


----------------------------------------------------------------------

Comment By: Duane Larson (duanelarson123)
Date: 2012-05-23 20:13

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

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2012-05-23 09:10

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


----------------------------------------------------------------------

Comment By: Duane Larson (duanelarson123)
Date: 2012-05-22 16:33

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

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2012-05-22 02:19

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3528675&group_id=232389



More information about the Devel mailing list