[Home]

Summary:ASTERISK-03363: Atxfer doesn't work (with oh323)
Reporter:mcisse (mcisse)Labels:
Date Opened:2005-01-27 03:32:43.000-0600Date Closed:2011-06-07 14:10:25
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I'm trying the new atxfer functionality. All seems to work fine at the beginning, but there is no audio between the party at the end of the transfer. Plus, after that, even normal calls won't work well (they can't hangup!).

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

Here is the dialplan:
[default]
exten => h,1,NoOp(bye)

exten => _6.,1,Dial(OH323/${EXTEN:1}|20|CrtT)
exten => _6.,2,Hangup

I'm doing the following manipulation:
Phone 41 dial 651.
Phone 51 ring and answer.
I dial *2642 on phone 41
Phone 42 ring and answer.
Phone 41 hang up.
I hear a beep in phone 42.
And now, there is no sound with 42 and 51 :-(
So, I hangup 51, then 42.

Here are the messages from Asterisk:

-- Executing Dial("OH323/R31698", "OH323/51|20|CrtT") in new stack
   -- H.323 call to 51 with codec(s) ulaw
   -- Called 51
   -- OH323/L29479 is ringing
   -- OH323/L29479 answered OH323/R31698
   -- Started music on hold, class 'default', on OH323/L29479
   -- Playing 'pbx-transfer' (language 'en')
   -- Executing Dial("Local/642@h323-b9d1,2", "OH323/42|20|CrtT") in
new stack
   -- H.323 call to 42 with codec(s) ulaw
   -- Called 42
   -- OH323/L29480 is ringing
   -- OH323/L29480 answered Local/642@h323-b9d1,2
   -- H.323 call 'ip$192.168.254.137:35504/31698' cleared, reason 4
(Cleared by remote user)
   -- Stopped music on hold on OH323/L29479
   -- Playing 'beep' (language 'en')
 == Spawn extension (h323, 651, 1) exited non-zero on 'OH323/R31698'
   -- Executing NoOp("OH323/R31698", "bye") in new stack
   -- Hungup 'OH323/R31698'
Comments:By: twisted (twisted) 2005-01-27 18:57:37.000-0600

This is DEFINATELY not major, considering OH323 isn't even part of asterisk. I would suggest talking to the devlopers of OH323 and see what they say.
By: Mark Spencer (markster) 2005-01-27 19:15:22.000-0600

Wow, I didn't even catch that.  Does this even belong here then?
By: twisted (twisted) 2005-01-27 20:32:59.000-0600

I guess not.  Closing.  If poster can provide evidence of asterisk at fault, and not oh323, poster may re-open.
By: mcisse (mcisse) 2005-01-28 04:30:19.000-0600

Same bug using only SIP
By: mcisse (mcisse) 2005-01-28 04:31:56.000-0600

Here are the messages from Asterisk using SIP:

*CLI>
   -- SIP Seeding '42' at 42@192.168.254.111:1719 for 60
   -- Registered SIP '41' at 192.168.254.71 port 1719 expires 14
   -- Executing Dial("SIP/41-398b", "SIP/51||CrtT") in new stack
   -- Called 51
   -- SIP/51-cba0 is ringing
   -- SIP/51-cba0 answered SIP/41-398b
   -- Attempting native bridge of SIP/41-398b and SIP/51-cba0
Jan 28 11:28:51 WARNING[32295]: chan_sip.c:1934 sip_indicate: Don't know how to indicate condition 16
   -- Started music on hold, class 'default', on SIP/51-cba0
   -- Playing 'pbx-transfer' (language 'fr')
   -- Executing Dial("Local/642@default-ce5f,2", "SIP/42||CrtT") in new stack
   -- Called 42
   -- SIP/42-29fc is ringing
   -- SIP/42-29fc answered Local/642@default-ce5f,2
   -- Stopped music on hold on SIP/51-cba0
   -- Playing 'beep' (language 'en')
 == Spawn extension (default, 651, 1) exited non-zero on 'SIP/41-398b'
 == Spawn extension (default, 642, 1) exited non-zero on 'Local/642@default-ce5f,2'

*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data          
   SIP/51-cba0  (default    s            1   )      Up (None)        (None)        
Local/642@default-ce5f,1  (default    s            1   )      Up Bridged Call                
2 active channel(s)
By: Mark Spencer (markster) 2005-01-28 10:14:35.000-0600

Find me on IRC, I will need to login and try to diagnose this with gdb in the SIP only configuration.
By: Mark Spencer (markster) 2005-01-28 10:15:01.000-0600

And to be sure, you're saying that you can no longer accept SIP calls after an attended transfer?
By: mcisse (mcisse) 2005-01-29 01:58:54.000-0600

After an attended transfer, SIP calls seem to be accepted succesfully. But, when calling an IVR menu (using background application, or playback) there is a problem at hangup time. In fact, it seems like Asterisk does not see the hangup, because dialplan continues to run the IVR menu, even after hangup.
Dialplan for dial:
exten => _6.,1,Dial(SIP/${EXTEN:1}||CrtT)
exten => _6.,2,Hangup
So, I'm the only one with this bug?
I'll try to find you on IRC monday or tuesday and give you an ssh access to my computer if needed.
By: mcisse (mcisse) 2005-02-02 09:37:42.000-0600

I've finally found why atxfer doesn't work.
First, you need to know that I'm running Asterisk as non-root.
Plus, I was using zaptelrtc.
When Asterisk is executed as root, no problem, atxfer works great.
As non-root, Asterisk works well (even MoH), but atxfer fail.
It's possibly related to zaptel although I have put /dev/zap/* and /dev/rtc into the correct group with rw attributes.
I don't know more for now.
By: Anthony Minessale (anthm) 2005-02-03 08:45:28.000-0600

So you can faithfully reproduce the bug ONLY by running as not root?
and this involves SIP to SIP calls only? are there any occurences of the bug on IAX or Zap ?

Isn't there something about underprivledged users only opening certian amount of fd?
By: mcisse (mcisse) 2005-02-03 09:16:27.000-0600

Yeah, I can only reproduce it as not root.
The bug is here using SIP or OH323 (seems independent of the protocol).
The bug is here also with 2 SIP Phones and 1 IAX Phone (not tested using only IAX).
Amount of descriptors is set to 70000 (done as root before launching asterisk).
/dev/zap/* and /dev/rtc is owned by correct group with rw (MoH works) ; but maybe it's not sufficient.
I'm using zaptelRTC on this configuration (rtcsetup launched as root as a background task).
The problem may come from zaptelRTC which may need superuser rigths (in that case, sorry for bothering you).
Maybe the atxfer uses some special operation on zaptel?
Later, I'll be able to test this using ztdummy, or even with a real Digium card.
The strange thing is that all other functionnalities work great!
By: mcisse (mcisse) 2005-02-08 07:27:12.000-0600

I've tryed with ztdummy (instead of zaptelrtc). Same problem when executed as non root. Anyway, it always works as root.
By: Anthony Minessale (anthm) 2005-02-11 13:42:37.000-0600

Should this change to a new issue since the root thing seems to be the real problem?
By: Mark Spencer (markster) 2005-02-11 16:38:16.000-0600

No, the bug in attended transfer should be fixed.  Find me on IRC and lets talk about why this might be caused.
By: Mark Spencer (markster) 2005-02-28 00:27:46.000-0600

Can you attach a debug with the attended transfer in the failed mode?
By: Olle Johansson (oej) 2005-03-17 08:13:46.000-0600

mcisse: We need feedback from you!

/Housekeeping
By: Brian West (bkw918) 2005-03-17 21:07:52.000-0600

Please respond if its still an issue.. since oh323 isn't included with asterisk and not many use it... this is a bit hard to debug or get feedback when you don't repsond.

Thanks,
/b