Summary: | ASTERISK-13375: One way voice after attended transfer | ||
Reporter: | radicalish (radicalish) | Labels: | |
Date Opened: | 2009-01-15 04:49:59.000-0600 | Date Closed: | 2011-06-07 14:07:53 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/CodecHandling |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) full.issue_14249 ( 1) full.issue_14249.2 | |
Description: | We have problem with one way voice in next scenario: 101 calls to 102, 102 takes second line and calls to IVR (number 1234) that have Answer() application and then call directed to 103 102 makes attended transfer while 103 is ringing, so now we have call between 101 (connected) and 103 (ringing) when 103 answers we get in CLI bulk of messages: [15 12:33:10] WARNING[3681] chan_sip.c: Asked to transmit frame type 64, while native formats is 0x8 (alaw)(8) read/write = 0x8 (alaw)(8)/0x 8 (alaw)(8) 101 can hear 103, but 103 can't only if 101 press any digit (sends DTMF) or press HOLD and UNHOLD, then we have two way voice. 101, 102 and 103 are SIP devices I attached full log with SIP debug | ||
Comments: | By: radicalish (radicalish) 2009-01-15 11:16:25.000-0600 there is similar issue in another scenario: 101 calls to IVR (number 1234) that have Answer() application and then call directed to 103, 103 doesn't want to answer and divert call (SIP 302 Moved Temporarily) to 102, 101 stops to hear ringing tones and we get in CLI bulk of messages: WARNING[5475] chan_sip.c: Asked to transmit frame type 64, while native formats is 0x8 (alaw)(8) read/write = 0x8 (alaw)(8)/0x8 (alaw)(8) when 102 answers audio come back to 101 I attached another log full.issue_14249.2 By: Digium Subversion (svnbot) 2009-01-23 14:16:12.000-0600 Repository: asterisk Revision: 170648 U branches/1.4/main/channel.c ------------------------------------------------------------------------ r170648 | file | 2009-01-23 14:16:12 -0600 (Fri, 23 Jan 2009) | 4 lines When a channel is answered make sure any indications currently playing stop. Usually the phone would do this but if the channel was already answered then they are being generated by Asterisk and we darn well need to stop them. (closes issue ASTERISK-13375) Reported by: RadicAlish ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=170648 By: Digium Subversion (svnbot) 2009-01-23 14:17:41.000-0600 Repository: asterisk Revision: 170652 _U trunk/ U trunk/main/channel.c ------------------------------------------------------------------------ r170652 | file | 2009-01-23 14:17:40 -0600 (Fri, 23 Jan 2009) | 11 lines Merged revisions 170648 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170648 | file | 2009-01-23 16:16:39 -0400 (Fri, 23 Jan 2009) | 4 lines When a channel is answered make sure any indications currently playing stop. Usually the phone would do this but if the channel was already answered then they are being generated by Asterisk and we darn well need to stop them. (closes issue ASTERISK-13375) Reported by: RadicAlish ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=170652 By: Digium Subversion (svnbot) 2009-01-23 14:19:15.000-0600 Repository: asterisk Revision: 170659 _U branches/1.6.0/ U branches/1.6.0/main/channel.c ------------------------------------------------------------------------ r170659 | file | 2009-01-23 14:19:14 -0600 (Fri, 23 Jan 2009) | 18 lines Merged revisions 170652 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r170652 | file | 2009-01-23 16:18:05 -0400 (Fri, 23 Jan 2009) | 11 lines Merged revisions 170648 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170648 | file | 2009-01-23 16:16:39 -0400 (Fri, 23 Jan 2009) | 4 lines When a channel is answered make sure any indications currently playing stop. Usually the phone would do this but if the channel was already answered then they are being generated by Asterisk and we darn well need to stop them. (closes issue ASTERISK-13375) Reported by: RadicAlish ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=170659 By: Digium Subversion (svnbot) 2009-01-23 14:20:13.000-0600 Repository: asterisk Revision: 170664 _U branches/1.6.1/ U branches/1.6.1/main/channel.c ------------------------------------------------------------------------ r170664 | file | 2009-01-23 14:20:13 -0600 (Fri, 23 Jan 2009) | 18 lines Merged revisions 170652 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r170652 | file | 2009-01-23 16:18:05 -0400 (Fri, 23 Jan 2009) | 11 lines Merged revisions 170648 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170648 | file | 2009-01-23 16:16:39 -0400 (Fri, 23 Jan 2009) | 4 lines When a channel is answered make sure any indications currently playing stop. Usually the phone would do this but if the channel was already answered then they are being generated by Asterisk and we darn well need to stop them. (closes issue ASTERISK-13375) Reported by: RadicAlish ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=170664 By: radicalish (radicalish) 2009-01-25 04:36:36.000-0600 svnbot: thanks for response I downloaded SVN-branch-1.4-r170836, but still have same problem with one difference: there are no WARNINGs. when 103 answers, he hears MOH, but 101 can hear 103 By: Joshua C. Colp (jcolp) 2009-02-10 12:08:08.000-0600 I've tried some more to try to determine what is happening here and failed. An updated log with my last changes would be extremely helpful. SIP traces are not needed. By: Leif Madsen (lmadsen) 2009-03-23 12:35:12 RadicAlish: Do you have the ability to get the information requested, or an ETA when you could provide the data? Or has the issue been resolved for you? By: Joshua C. Colp (jcolp) 2009-04-15 12:53:53 Suspended due to lack of response. |