Summary: | ASTERISK-05837: Festival doesn't work folling a "Ringing" (Asked to transmit frame type 64, while native formats is 4) | ||
Reporter: | boatright (boatright) | Labels: | |
Date Opened: | 2005-12-13 18:11:35.000-0600 | Date Closed: | 2006-01-17 13:16:48.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Applications/app_festival |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | I've reduced my problem to this simple testcase: exten => 7054,1,Answer exten => 7054,n,Ringing exten => 7054,n,Wait(1) exten => 7054,n,Festival(mary had a little lamb) exten => 7054,n,Hangup When I call this extension, I do not hear "mary had a little lamb" and my console fills up with messages like this one: Dec 13 18:58:41] WARNING[412]: chan_sip.c:2520 sip_write: Asked to transmit frame type 64, while native formats is 4 (read/write = 4/4) If I remove the Ringing command, however, Festival speaks the expected words just fine: exten => 7054,1,Answer ;exten => 7054,n,Ringing exten => 7054,n,Wait(1) exten => 7054,n,Festival(mary had a little lamb) exten => 7054,n,Hangup Things get complicated by the fact that the problem only occurs on a SIP channel using a ulaw codec (at least that's the only case I've discovered). A Zap channel does not exhibit the problem at all. Let me know what additional debug info is needed. | ||
Comments: | By: twisted (twisted) 2005-12-14 12:49:25.000-0600 You should answer the channel before doing anything like this. Actually, app_festival should answer the channel if it's not already. I'll see about tossing a patch up for that soon. By: twisted (twisted) 2005-12-14 12:51:38.000-0600 actually, the code answers the channel, but it looks like festival wants to write signed linear, so it sets the channel's write format to slin and attempts to write that. By: boatright (boatright) 2005-12-14 13:42:31.000-0600 Note that I do have an "Answer" command in my example above. By: Matt O'Gorman (mogorman) 2006-01-17 13:16:35.000-0600 fixed in 1.2 and trunk with commits 8140 and 8141 respectively |