[Home]

Summary:ASTERISK-09435: Dial command always bridge calls directly when a call transfer is requested
Reporter:unservices (unservices)Labels:
Date Opened:2007-05-14 10:30:06Date Closed:2007-06-21 11:05:49
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 9721-noopt.diff
Description:Two scenarios, same results...

1) A call comes in from a trunk [A], and is mapped to ring extension [101] which is a linksys pap2 device. With the *72 config, the device then responds that this call should be redirected to a different number (MOVED TEMPORARLY), so asterisk gets another trunk [B] and makes a call out to the number, then connects the trunk [A] to the trunk [B]. Both trunks are SIP, and canreinvite=no. Since there are two calls happening, the MySQL CDR record would have two information (which is correct), but the second call does not record the billsec although the status is saved as ANSWERED ;

2) A call comes in from a trunk [A], and is mapped to ring extension [101] which is now a polycom soundip device. The call is answered on the device, and then we transfer the call using the device command. Asterisk gets another trunk [B] and makes a call out to the number, then connects the trunk [A] to the trunk [B]. Both trunks are SIP, and canreinvite=no. Since there are two calls happening, the MySQL CDR record would have two information (which is correct), but the second call does not record the billsec although the status is saved as ANSWERED again;

ALSO, in both cases we have an AGI script running (yes, we tested above without it, same results). We see that the script is not "pausing" in the dial command, instead it sounds that is not respecting even the parameters HhTt that we included to make sure asterisk would not bridge them directly. Despite of using these parameters, we cannot terminate the call with * or transfer pressing # (really don't need, but was used to test if the dial is accepting it).

The voice is passing properly both ways, despite the msg of result=-1 in the attempt of bridge. We could not find anything else wrong other than cdr records (which is big because we need to do billing!).

EVERYTHING ELSE during regular calls (non-transfer) is working and saving properly. The script does wait the regular calls to end before continuing, etc.


****** ADDITIONAL INFORMATION ******

AGI Debugging Enabled
   -- Executing DeadAGI("SIP/link1-081b5310", "inbound-init.php")
   -- Launched AGI Script /var/lib/asterisk/agi-bin/inbound-init.php
AGI Tx >> agi_request: inbound-init.php
AGI Tx >> agi_channel: SIP/link1-081b5310
AGI Tx >> agi_language: en
AGI Tx >> agi_type: SIP
AGI Tx >> agi_uniqueid: 1179154208.50
AGI Tx >> agi_callerid: 4071111111
AGI Tx >> agi_calleridname: CALLER ORIGINATING
AGI Tx >> agi_callingpres: 0
AGI Tx >> agi_callingani2: 0
AGI Tx >> agi_callington: 0
AGI Tx >> agi_callingtns: 0
AGI Tx >> agi_dnid: 4072222222
AGI Tx >> agi_rdnis: unknown
AGI Tx >> agi_context: trunk1-trunk
AGI Tx >> agi_extension: 4072222222
AGI Tx >> agi_priority: 1
AGI Tx >> agi_enhanced: 0.0
AGI Tx >> agi_accountcode:
AGI Tx >>
   -- AGI Script inbound-init.php completed, returning 0
   -- Executing Dial("SIP/trunk1-081b5310", "SIP/linksys_pap2|30|rg")
   -- Called linksys_pap2
   -- Got SIP response 302 "Moved Temporarily" back from x.x.x.x
   -- Now forwarding SIP/trunk1-081b5310 to 'Local/4073333333@clients-outbound' (thanks to SIP/linksys_pap2-081ba850)
   -- Executing DeadAGI("Local/4073333333@clients-outbound-5b4d,2", "outbound.php") in new stack
   -- Launched AGI Script /var/lib/asterisk/agi-bin/outbound.php
AGI Tx >> agi_request: outbound.php
AGI Tx >> agi_channel: Local/4073333333@clients-outbound-5b4d,2
AGI Tx >> agi_language: en
AGI Tx >> agi_type: Local
AGI Tx >> agi_uniqueid: 1179154212.53
AGI Tx >> agi_callerid: 4071111111
AGI Tx >> agi_calleridname: CALLER ORIGINATING
AGI Tx >> agi_callingpres: 0
AGI Tx >> agi_callingani2: 0
AGI Tx >> agi_callington: 0
AGI Tx >> agi_callingtns: 0
AGI Tx >> agi_dnid: unknown
AGI Tx >> agi_rdnis: 4072222222
AGI Tx >> agi_context: clients-outbound
AGI Tx >> agi_extension: 4073333333
AGI Tx >> agi_priority: 1
AGI Tx >> agi_enhanced: 0.0
AGI Tx >> agi_accountcode: un-test
AGI Tx >>
AGI Rx << EXEC Dial SIP/trunk1-trunk/4073333333|120|h
   -- AGI Script Executing Application: (Dial) Options: (SIP/trunk1-trunk/4073333333|120|HhTt)
   -- Called trunk1-trunk/4073333333
   -- SIP/trunk1-trunk-081ba850 is ringing
   -- Local/4073333333@clients-outbound-5b4d,1 is ringing
   -- SIP/trunk1-trunk-081ba850 is making progress passing it to Local/4073333333@clients-outbound-5b4d,2
   -- Local/4073333333@clients-outbound-5b4d,1 is making progress passing it to SIP/unservices2-081b5310
   -- SIP/trunk1-trunk-081ba850 answered Local/4073333333@clients-outbound-5b4d,2
   -- Local/4073333333@clients-outbound-5b4d,1 answered SIP/trunk1-081ba850
   -- Attempting native bridge of SIP/unservices2-081b5310 and SIP/trunk1-trunk-081ba850
AGI Tx >> 200 result=-1
AGI Rx << GET VARIABLE ANSWEREDTIME
AGI Tx >> 200 result=0
   -- AGI Script outbound.php completed, returning 0
Comments:By: Joshua C. Colp (jcolp) 2007-05-14 11:27:03

That is being done purposely. There are actually 4 channels involved:

A <-> B
C <-> D

B and C exchange frames back and forth.

In order to optimize things B and C have the capability to remove themselves from the bridge and have A and D talk directly to eachother. This is why you are seeing those CDR records. As soon as the bridge is up this optimization happens. As for the transfer/hangup/thing as soon as the optimization happens The dial between C and D is gone, so the options no longer apply. If you really want to not have this happen... you can modify the source code in app_dial where it creates a Local channel and add /n to the end of the dial string. That disables the optimization.

I am however assigning this to the current CDR expert who is rewriting CDR stuff in trunk.
By: unservices (unservices) 2007-05-14 11:40:11

First of all, thanks for the reply.

I understand your point regarding the optimization, but looking from a "billing perspective", considering that we are still paying for the inbound trunk and also now paying for the outbound trunk, it must have a way to track both channels (so that customer can be charged).

If I may ask, the app_dial.c does have almost 2000 lines of code, and I'm really still a little bit lost there. If you could post some reference points for me to find the place where it creates a local channel (and needs the /n), it would really help!

I'm not sure about performance implications on this, but from a business perspective we need to balance between the billing/CDR and performance. Assuming that not many times we will have a call forward (and therefore this issue), performance might not be extremely compromised...
By: Joshua C. Colp (jcolp) 2007-05-14 11:50:09

It is well known that the current CDR implementation is not what people need, that is why it is being drastically rewritten. Attached is a patch to make the Local channels hang around some more. Whether this will yield exactly what you want who knows...
By: Steve Murphy (murf) 2007-05-14 13:41:27

Uh, OK; try file's suggested mod, and see if that, for some strange reason, clears up the problem. If it doesn't, then, I'll sift thru the code, and see how I might mod the CDR code to better track that last leg.
By: unservices (unservices) 2007-05-14 15:47:15

It reasonably solved the problem! Here are the tests we did...

First we did the blind transfer with the pap2 / moved temporarly message (using the *72 feature), it kept the details of both legs separately in the CDR as expected, and the billsec times were correct. Perfect !!!

Then with a polycom phone we answered the call and then did a transfer request. In the CDR details we got both legs again, but the values are all updated with the info from the last leg. So for example you receive a call in the phone, talk for a couple of minutes, then transfer to another person which ends talking for 30 sec, the billed time is only the 30 sec on each CDR detail... The correct would be the first record (incomming call) to be the total time 2min30sec and the second record (forwarded) to be the 30sec of transfered.

So it sounds that now is just a bug of the CDR in how it's updating the records...We quite understand your position about the CDR implementation not being what is needed. Considering that we are buying voip origination and termination, we pay on both sides, and it's very important to keep track of the costs. To our knowledge the only way to see this is through the CDR, so that's why we are having all possible attention...

If there is a list regarding features and ideas for the new CDR, let us know and we will be more than happy to contribute!
By: Joshua C. Colp (jcolp) 2007-06-21 11:05:48

Closing this out since the bug has now been isolated/patch provided, and explained. CDR changes continue to be ongoing... yay!