|Summary:||ASTERISK-01324: PLEASE HELP! Transfered call gets dropped 1 sec later|
|Date Opened:||2004-04-01 10:35:58.000-0600||Date Closed:||2011-06-07 14:05:09|
|Description:||When doing a call E1->IAX2->MGCP and then doing a transfer MGCP->IAX2->E1 the call gets dropped after 1 sec. Actually is something strange, on the E1-IAX2 box the call is still active, but the IAX2-MGCP box there are no active channels! Any hints??|
I've tried to figure it out, however I'm really pissed off now after looking for the bug since a couple days... PLEASE HELP!
****** ADDITIONAL INFORMATION ******
-- Attempting native bridge of IAX2[ast-e1]/4 and IAX2[ast-e1]/3
-- Channel 'IAX2[ast-e1]/3' ready to transfer
-- Channel 'IAX2[ast-e1]/4' ready to transfer
-- Releasing IAX2[ast-e1]/4 and IAX2[ast-e1]/3
Apr 1 17:01:03 DEBUG: channel.c:2318 ast_channel_bridge: Bridge stops because we're zombie or need a soft hangup: c0=NCS/aaln/2@mta0004BD9C1C44.wasi.tv-0, c1=NCS/aaln/2@mta0004BD9C1C44.wasi.tv-1<ZOMBIE>, flags: No,No,Yes,Yes
Apr 1 17:01:03 DEBUG: channel.c:2433 ast_channel_bridge: Bridge stops bridging channels NCS/aaln/2@mta0004BD9C1C44.wasi.tv-0 and NCS/aaln/2@mta0004BD9C1C44.wasi.tv-1<ZOMBIE>
== Spawn extension (default, 1000, 1) exited non-zero on 'NCS/aaln/2@mta0004BD9C1C44.wasi.tv-0'
Apr 1 17:01:15 DEBUG: channel.c:2333 ast_channel_bridge: Returning from native bridge, channels: IAX2[ast-e1]/1, IAX2[ast-e1]/4
Apr 1 17:01:15 DEBUG: chan_iax2.c:1953 iax2_hangup: We're hanging up IAX2[ast-e1]/4 now...
Apr 1 17:01:15 DEBUG: chan_iax2.c:1962 iax2_hangup: Really destroying IAX2[ast-e1]/4 now...
-- Hungup 'IAX2[ast-e1]/4'
== Spawn extension (default, 06505757009, 1) exited non-zero on 'IAX2[ast-e1]/1'
Apr 1 17:01:15 DEBUG: chan_iax2.c:1953 iax2_hangup: We're hanging up IAX2[ast-e1]/1 now...
Apr 1 17:01:15 DEBUG: chan_iax2.c:1962 iax2_hangup: Really destroying IAX2[ast-e1]/1 now...
-- Hungup 'IAX2[ast-e1]/1'
|Comments:||By: Mark Spencer (markster) 2004-04-02 02:12:15.000-0600|
This isn't a hangup, this is a transfer running an IAX2 native bridge. The call should remain up on ast-e1 but there is no reason for it to remain on the server that you transferred the call from.
By: flying_sushi (flying_sushi) 2004-04-08 11:37:08
markster, yes you're right the call remains up, but the voice channels are muted. i can't hear the other side and vice versa. when I do a *72 forward to a PSTN number, the same problem occurs. when I use "Dial" within the extension.conf to dial a number on the PSTN, same problem. So, basically everything that gets transfered back to ast-e1 via IAX2, gets muted. however, the channels remain up on ast-e1. I really think this should be considered as a bug.
By: Mark Spencer (markster) 2004-04-09 11:04:59
You can turn off the ability to do the transfer if you want. Just set "notransfer = yes" in your friend declaration.
By: flying_sushi (flying_sushi) 2004-04-13 04:12:39
markster, setting notransfer=yes does exactly nothing. however, I've commented the code within chan_iax2.c that does the transfer part, it works now. the stay up and I'm able to do transfer/callforward without being muted. that however, is not a vaild solution for me, i have a 2 mbit leased and when doing transfers it eats up all my bandwidth.
By: Mark Spencer (markster) 2004-04-13 09:51:52
You need to find me on IRC, but you can't keep taking 5 days to get back to us. This bug is one of only a handful that are between here and Asterisk 1.0-RC1, so you need to be much more prompt especially given this is a bug that no one else has duplicated so far. Also, can you confirm that you do not have the jitter buffer enabled in your iax.conf? thanks.
By: flying_sushi (flying_sushi) 2004-04-14 05:43:29
markster, sorry for that, i've been a couple days off. I've set jitterbuffer=no, same problem. i'll give it a try with 0.9.0.
By: Mark Spencer (markster) 2004-04-14 14:44:05
please try with cvs head!
By: Mark Spencer (markster) 2004-04-15 15:14:34
Did it work with CVS head?
By: Brian West (bkw918) 2004-04-17 22:53:54
If it didn't work please find kram or bkw_ on IRC and we will reopen.