Summary:ASTERISK-02683: h323 calls gets recorded by voicemail application at double speed if voicemail format is .wav
Reporter:mdu113 (mdu113)Labels:
Date Opened:2004-10-26 13:18:33Date Closed:2004-12-15 21:49:10.000-0600
Versions:Frequency of
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.


pwlib 1.5.2
openh323 1.12.2
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[376855]:     -- Playing 'beep' (language 'en')
Nov  1 12:32:29 DEBUG[376855]: Set channel H323/ip$ to write format ULAW
Nov  1 12:32:30 VERBOSE[376855]:     -- Recording the message
Nov  1 12:32:30 DEBUG[376855]: play_and_record: <None>, /usr/local/asterisk/var/spool/asterisk/voicemail/xyz/12128121207/INBOX/msg0001, 'wav'
Nov  1 12:32:30 DEBUG[376855]: Recording Formats: sfmts=wav
Nov  1 12:32:30 VERBOSE[376855]:     -- x=0, open writing:  /usr/local/asterisk/var/spool/asterisk/voicemail/xyz/12128121207/INBOX/msg0001 format: wav, 0x8179678
Nov  1 12:32:30 DEBUG[376855]: Set channel H323/ip$ to read format SLINR
Nov  1 12:32:30 DEBUG[114695]: Allocating new SIP call for (null)
Nov  1 12:32:30 DEBUG[114695]: Setting NAT on RTP to 4
Nov  1 12:32:30 DEBUG[114695]: Stopping retransmission on '017357b71971ae3f4ae309e703d03698@' of Request 102: Found
Nov  1 12:32:37 VERBOSE[376855]:     -- User hung up
Nov  1 12:32:37 DEBUG[376855]: Set channel H323/ip$ to read format ULAW
Nov  1 12:32:37 DEBUG[376855]: H323/ip$ 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?

-- Housekeeping

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!