|Summary:||ASTERISK-02683: h323 calls gets recorded by voicemail application at double speed if voicemail format is .wav|
|Date Opened:||2004-10-26 13:18:33||Date Closed:||2004-12-15 21:49:10.000-0600|
|Environment:||Attachments:||( 0) console.log|
( 1) debug.log
|Description:||If h.323 call gets into voicemail and voicemail is set to record message in wav format, the message is recorded at double speed so it's almost impossible to recognize what was said. It works fine for SIP calls though. Also it seems to work fine if voicemail records messages in any compressed format (tried gsm and wav49).|
Please let me know what debugging info you need me to collect.
****** ADDITIONAL INFORMATION ******
|Comments:||By: Andrey S Pankov (casper) 2004-10-30 08:31:52|
Do you mean an incoming h323 call? What codec are you using for h323 calls?
By: mdu113 (mdu113) 2004-10-30 14:05:39
Yes, incoming h323 call. The codec is ulaw.
By: Andrey S Pankov (casper) 2004-10-31 14:46:10.000-0600
How many frames do you have in your uLaw stream?
Would you like to show us some logs (asterisk console, h.323 trace 5, etc)?
By: mdu113 (mdu113) 2004-11-01 11:55:44.000-0600
Actually I'm not sure how many frames I have in ulaw stream. I haven't seen the way to control it in h323.conf. Looking at source code it seems to be hardcoded to 30 frames per packet. As everything sounds fine when incoming h323 call answered by sip phone and the only problem is when it gets into voicemail I've never thought there could be a problem there and never bothered to look in that direction. May be I should change my mind.
Anyway console.log is asterisk console output of a trouble call. debug.log is relevant excerpt of asterisk's debug log.
By: Andrey S Pankov (casper) 2004-11-01 12:46:21.000-0600
Nov 1 12:32:28 VERBOSE: -- Playing 'beep' (language 'en')
Nov 1 12:32:29 DEBUG: Set channel H323/ip$220.127.116.11:57070/12334 to write format ULAW
Nov 1 12:32:30 VERBOSE: -- Recording the message
Nov 1 12:32:30 DEBUG: play_and_record: <None>, /usr/local/asterisk/var/spool/asterisk/voicemail/xyz/12128121207/INBOX/msg0001, 'wav'
Nov 1 12:32:30 DEBUG: Recording Formats: sfmts=wav
Nov 1 12:32:30 VERBOSE: -- x=0, open writing: /usr/local/asterisk/var/spool/asterisk/voicemail/xyz/12128121207/INBOX/msg0001 format: wav, 0x8179678
Nov 1 12:32:30 DEBUG: Set channel H323/ip$18.104.22.168:57070/12334 to read format SLINR
Nov 1 12:32:30 DEBUG: Allocating new SIP call for (null)
Nov 1 12:32:30 DEBUG: Setting NAT on RTP to 4
Nov 1 12:32:30 DEBUG: Stopping retransmission on 'email@example.com' of Request 102: Found
Nov 1 12:32:37 VERBOSE: -- User hung up
Nov 1 12:32:37 DEBUG: Set channel H323/ip$22.214.171.124:57070/12334 to read format ULAW
Nov 1 12:32:37 DEBUG: H323/ip$126.96.36.199:57070/12334 hungup
"Set channel to read format ULAW -> SLINR -> ULAW"
Does it happen to a SIP call?
By: Andrey S Pankov (casper) 2004-11-01 12:53:59.000-0600
May be "dataType = audioData g711Ulaw64k 30" for forwarg logical channel and "dataType = audioData g711Ulaw64k 10" confuse VoiceMail?
Try to bug VoiceMail anyway if you want this to be fixed... and do not use chan_h323 ;)
By: mdu113 (mdu113) 2004-11-01 13:46:59.000-0600
Yes, it happens for SIP calls too. The logs seems to be identical (with exception of channel names) for SIP and H323 calls. Results are very different unfortunately.
I wish I could get rid of h323. It's out of my control.
You think it's better file a bug in Applications? It happens to h323 calls only, so I thought this is the most appropriate place for this bugreport.
By: Andrey S Pankov (casper) 2004-11-01 14:02:03.000-0600
You are right, but the bug will never be fixed if filed in h323. :( There are chances that someone will point you to the right solution only if you bug VoiceMail. Unfortunately, I suppose common asnwer will be not to use chan_h323.
Please try to force both endpoints to use the same frames number. Then we'll see...
By: mdu113 (mdu113) 2004-11-02 11:36:06.000-0600
My h323 gateway doesn't allow setting more than 10 frames per packet with default to 4. So I altered ast_h323.cpp to use 4 g711Frames also and recompiled it. It didn't help. I can't see any differences.
I'll try to file the bugreport to Applications also as you're suggesting and hope they won't curse me out for that ;)
By: Brian West (bkw918) 2004-11-02 12:41:17.000-0600
casper ONE BUG, ONE PROBLEM. You can't tell people to open the bug again that just splits focus on the problem.
By: Russell Bryant (russell) 2004-11-14 21:54:51.000-0600
Is this still an issue?
By: mdu113 (mdu113) 2004-11-15 11:07:37.000-0600
Yes. It's definitely an issue in 1.0.2. Haven't tried cvs.
By: twisted (twisted) 2004-12-01 00:51:36.000-0600
Issue in cvs-HEAD? how about cvs-STABLE? We really need to know if this bug is simply in the tarball or if it exists also in cvs (either).
By: mdu113 (mdu113) 2004-12-01 11:48:33.000-0600
Just checked cvs-stable. Issue is there.
CVS-head uses newer openh323 and pwlib libraries and unfortunately I don't have a spare machine to play with at the moment. I'll try to work something out, but it may take some time.
By: twisted (twisted) 2004-12-15 20:46:03.000-0600
It's been two weeks. have you made any progress?
By: jerjer (jerjer) 2004-12-15 21:46:08.000-0600
Not an issue on cvs -head. Reopen if you have proof otherwise.
By: twisted (twisted) 2004-12-15 21:49:10.000-0600
Please mark closed if bug is finished, and no patch required to resolve. Thanks!