[Home]

Summary:ASTERISK-05453: [patch] No audio on ATXFER
Reporter:jalsot (jalsot)Labels:
Date Opened:2005-11-04 10:09:15.000-0600Date Closed:2010-09-21 17:58:11
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) atxfer.patch
Description:When making ATXFER, the transfer is successfull, however no voice/audio can be heared. After some investigation I found, that the ast_bridge_call_thread thread has not been started and this caused the trouble.
Removing the setschedpolicy fixed the trouble.
Comments:By: Kevin P. Fleming (kpfleming) 2005-11-07 20:16:48.000-0600

We will need more details on your system to understand this one... there is no reason that setting the scheduling policy should cause this sort of thing.

Are you saying that the thread creation failed, or that the thread was just not processing audio?
By: jalsot (jalsot) 2005-11-08 02:29:40.000-0600

To be honest, I'm not a well experienced C/unix coder - I don't know exactly what that line makes. However if I remove it, everything works fine.
What I did:
put many ast_log lines into code, run asterisk and was checking where things are going. I found that the mentioned thread was not started - no log was written (I hope it is possible to use ast_log in a new thread:). Then I wrote the result of result = ast_pthread_create(&thread, &attr,ast_bridge_call_thread, data); into log and seen that it was 1 - which means, the thread was not started.
My thinking can be wrong however...
I run asterisk as a non-root user, just came into my mind. I can try to put back the line and see if it works when I run as root - or this has nothing to do with the problem.
What details should I provide to help?
By: Kevin P. Fleming (kpfleming) 2005-11-08 18:59:31.000-0600

Thanks for that; that's probably enough information for me to go on.
By: Kevin P. Fleming (kpfleming) 2005-11-08 19:25:44.000-0600

OK, I have fixed this in CVS HEAD by separating the thread creation from the scheduler policy setting; if the policy setting fails, the thread will continue to operate as normal.
By: Digium Subversion (svnbot) 2008-01-15 15:55:03.000-0600

Repository: asterisk
Revision: 7035

U   trunk/ChangeLog
U   trunk/res/res_features.c

------------------------------------------------------------------------
r7035 | kpfleming | 2008-01-15 15:55:02 -0600 (Tue, 15 Jan 2008) | 2 lines

issue ASTERISK-5453

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=7035
By: Digium Subversion (svnbot) 2010-09-21 16:58:14

Repository: asterisk
Revision: 288112

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r288112 | tilghman | 2010-09-21 16:58:13 -0500 (Tue, 21 Sep 2010) | 15 lines

Try both the encoded and unencoded subscription URI for a match in hints.

When a phone sends an encoded URI for a subscription, the URI is not matched
with the actual hint that is in decoded format.  For example, if we have an
extension with a hint that is named: "ASTERISK-5453" or "*5601", the subscription will
work fine if the phone subscribes with an already decoded URI, but when it's
decoded like "%255601" or "%2A5601", Asterisk is unable to match it with the
correct hint.

(closes issue ASTERISK-16495)
Reported by: ramonpeek
Patches:
      20100831__issue17785.diff.txt uploaded by tilghman (license 14)
Tested by: ramonpeek

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=288112
By: Digium Subversion (svnbot) 2010-09-21 16:59:47

Repository: asterisk
Revision: 288113

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r288113 | tilghman | 2010-09-21 16:59:47 -0500 (Tue, 21 Sep 2010) | 22 lines

Merged revisions 288112 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r288112 | tilghman | 2010-09-21 16:58:13 -0500 (Tue, 21 Sep 2010) | 15 lines
 
 Try both the encoded and unencoded subscription URI for a match in hints.
 
 When a phone sends an encoded URI for a subscription, the URI is not matched
 with the actual hint that is in decoded format.  For example, if we have an
 extension with a hint that is named: "ASTERISK-5453" or "*5601", the subscription will
 work fine if the phone subscribes with an already decoded URI, but when it's
 decoded like "%255601" or "%2A5601", Asterisk is unable to match it with the
 correct hint.
 
 (closes issue ASTERISK-16495)
  Reported by: ramonpeek
  Patches:
        20100831__issue17785.diff.txt uploaded by tilghman (license 14)
  Tested by: ramonpeek
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=288113
By: Digium Subversion (svnbot) 2010-09-21 17:57:23

Repository: asterisk
Revision: 288159

_U  branches/1.8/
U   branches/1.8/channels/chan_sip.c

------------------------------------------------------------------------
r288159 | tilghman | 2010-09-21 17:57:23 -0500 (Tue, 21 Sep 2010) | 29 lines

Merged revisions 288113 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r288113 | tilghman | 2010-09-21 16:59:46 -0500 (Tue, 21 Sep 2010) | 22 lines
 
 Merged revisions 288112 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r288112 | tilghman | 2010-09-21 16:58:13 -0500 (Tue, 21 Sep 2010) | 15 lines
   
   Try both the encoded and unencoded subscription URI for a match in hints.
   
   When a phone sends an encoded URI for a subscription, the URI is not matched
   with the actual hint that is in decoded format.  For example, if we have an
   extension with a hint that is named: "ASTERISK-5453" or "*5601", the subscription will
   work fine if the phone subscribes with an already decoded URI, but when it's
   decoded like "%255601" or "%2A5601", Asterisk is unable to match it with the
   correct hint.
   
   (closes issue ASTERISK-16495)
    Reported by: ramonpeek
    Patches:
          20100831__issue17785.diff.txt uploaded by tilghman (license 14)
    Tested by: ramonpeek
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=288159
By: Digium Subversion (svnbot) 2010-09-21 17:58:11

Repository: asterisk
Revision: 288160

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r288160 | tilghman | 2010-09-21 17:58:10 -0500 (Tue, 21 Sep 2010) | 36 lines

Merged revisions 288159 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r288159 | tilghman | 2010-09-21 17:57:22 -0500 (Tue, 21 Sep 2010) | 29 lines
 
 Merged revisions 288113 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r288113 | tilghman | 2010-09-21 16:59:46 -0500 (Tue, 21 Sep 2010) | 22 lines
   
   Merged revisions 288112 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r288112 | tilghman | 2010-09-21 16:58:13 -0500 (Tue, 21 Sep 2010) | 15 lines
     
     Try both the encoded and unencoded subscription URI for a match in hints.
     
     When a phone sends an encoded URI for a subscription, the URI is not matched
     with the actual hint that is in decoded format.  For example, if we have an
     extension with a hint that is named: "ASTERISK-5453" or "*5601", the subscription will
     work fine if the phone subscribes with an already decoded URI, but when it's
     decoded like "%255601" or "%2A5601", Asterisk is unable to match it with the
     correct hint.
     
     (closes issue ASTERISK-16495)
      Reported by: ramonpeek
      Patches:
            20100831__issue17785.diff.txt uploaded by tilghman (license 14)
      Tested by: ramonpeek
   ........
 ................
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=288160