headers
Norman Franke | 19 Aug 18:42

Possible Deadlock?

I had a deadlock today using 1.4.21.1. I had asterisk dump core to  
explore in GDB. Thread 32 is waiting for the "channels" lock held by  
21 while holding a channel lock. Thread 21 is then waiting for a lock  
on a channel held by 32 while holding a lock on "channels".

However, I can't figure out how thread 32 got the lock in the first  
place. Perhaps from this in the log?

[Aug 19 10:55:26] VERBOSE[25324] logger.c:     -- Got SIP response 480  
"Temporarily Unavailable" back from 172.16.22.30

And it never released the lock? I see in chan_sip.c:12936

                                 /* XXX Locking issues?? XXX */

This has only happened once recently.

Thread 32 (process 25324):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7edd56e in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/ 
libpthread.so.0
#2  0xb7eda179 in _L_mutex_lock_141 () from /lib/tls/i686/cmov/ 
libpthread.so.0
#3  0xb786a918 in ?? ()
#4  0x0807d514 in ast_cdr_start (cdr=0x815a148) at cdr.c:689
#5  0x0807fd3f in ast_mutex_lock (pmutex=0x815a148) at /usr/src/ 
asterisk-1.4.21.1/include/asterisk/lock.h:755
#6  0x08081795 in ast_channel_alloc (needqueue=0, state=0,  
cid_num=0xb7358a4d "6106421787", cid_name=0x8150810 "",
     acctcode=0x8150810 "", exten=0xb7358a05 "8827",
(Continue reading)

Permalink | Reply | 4 comments |
headers
Philipp Kempgen | 19 Aug 16:00

ExtensionStatus

1.6.1 doc/manager_1_1.txt:
> - The ExtensionStatus manager command now has a "StatusDesc" field with text description of the state

There is no ExtensionStatus manager command. It probably refers
to the *response* to the *ExtensionState* command.
But it doesn't have a StatusDesc field.
main/manager.c, action_extensionstate():
---cut---
	astman_append(s,   "Message: Extension Status\r\n"
			   "Exten: %s\r\n"
			   "Context: %s\r\n"
			   "Hint: %s\r\n"
			   "Status: %d\r\n\r\n",
			   exten, context, hint, status);
---cut---

Grüße,
Philipp Kempgen
--

-- 
http://www.das-asterisk-buch.de  -  http://www.the-asterisk-book.com
Amooma GmbH - Bachstr. 126 - 56566 Neuwied  ->  http://www.amooma.de
Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark Lynch | 19 Aug 01:30

Curly Asterisk <-> Voxbone problem

Hi All,

I've been pulling my hair out over this problem and hopefully someone on this list will be able to help.

Here is the situation:

Staging:
I've had an asterisk staging machine set up for a couple of months in preparation for going live with a project.  It is running Ubuntu Server 8.04 x86 with asterisk 1.4.17-dfsg.2ubuntu1
It is connected via voxbone to the PSTN network and everything is working fine. 

Production:
I have just installed our production box which is on a different network but is connected straight to the internet - no firewalls etc.
It is running Ubuntu Server 8.04 amd64 with asterisk 1.4.17-dfsg.2ubuntu1 and an identical configuration (I copied all the files across directly as part of debugging this problem)
I can connect to this box via sip - and I can see the call happening but the rtp is going to the wrong destination.

I have be working with voxbone to try to resolve this but it looks like the asterisk server on the production machine is not responding correctly with it's RTP streams.  The voxbone number is part of their new configuration where the SIP connection comes from a central SBC server (81.201.82.39) but the RTP is transmitted to and from the local POP - in snippet below from working server (81.201.84.141).  

When connections are coming to the Production box it is incorrectly sending the RTP traffic to the sip originating box, i.e.81.201.82.39 instead 81.201.84.141 and so no audio is working.

NOTE: I am using the exact same voxbone number - I have reconfigured it between tests to see if it was a problem with their new configuration but my staging machine seems to work perfectly but the production one does not.

Questions from this are:
 - Could this be a problem with the AMD64 build or is this very unlikely.
 - How can I get more information to debug this better?
 - Could this possibly be a bug in asterisk only on AMD64 builds?

I've attached some traces from the calls below:

RTP data flow from working server:
 17.328338 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19838, Time=32000
 17.348335 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19839, Time=32160
 17.368336 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19840, Time=32320
 17.388337 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19841, Time=32480
 17.408337 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19842, Time=32640
 17.428337 203.206.181.174 -> 81.201.84.141 RTP PT=ITU-T G.711 PCMA, SSRC=0x670F1498, Seq=19843, Time=32800

But the RTP data from the production (non working) server sends the RTP to 81.201.82.39

 9.673564 81.201.82.39 -> 63.138.188.91 SIP/SDP Request: INVITE sip:61390015580 <at> 63.138.188.91, with session description
  9.673961 63.138.188.91 -> 81.201.82.39 SIP Status: 100 Trying
  9.674207 63.138.188.91 -> 81.201.82.39 SIP/SDP Status: 200 OK, with session description
  9.918465 81.201.82.39 -> 63.138.188.91 SIP Request: ACK sip:61390015580 <at> 63.138.188.91
 10.716189 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34349, Time=160
 10.735624 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34350, Time=320
 10.755612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34351, Time=480
 10.775612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34352, Time=640
 10.795612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34353, Time=800
 10.799790 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
 10.815611 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34354, Time=960
 10.818728 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
 10.835608 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34355, Time=1120
 10.839226 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
 10.855605 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34356, Time=1280
 10.859224 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
 10.875612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34357, Time=1440
 10.879217 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
 10.895612 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34358, Time=1600
 10.899216 81.201.82.39 -> 63.138.188.91 ICMP Destination unreachable (Port unreachable)
 10.915610 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34359, Time=1760
 10.935609 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34360, Time=1920
 10.955611 63.138.188.91 -> 81.201.82.39 RTP PT=ITU-T G.711 PCMA, SSRC=0x68265F0D, Seq=34361, Time=2080

Any help or suggestions greatly appreciated.
Thanks,
Mark
--
OnScreen and Voice Learning and Assessment
www.learnosity.com

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply | 2 comments |
headers
Daniel Ferrer | 18 Aug 19:48

sip_devicestate and queue problems

Hi list,

We're using asterisk 1.4.21.1 in a callcenter enviroment, with some
queues, some of them relatively big queues (80 - 100 SIP agents, Xlite).
Normally, all agents are busy and there are 30-40 calls  waiting in the 
queue. We used 1.2 in the past and we migrated to 1.4 to take advantage 
of "autofill=yes" in app_queue.

We experienced some kind of trouble with "InUse" state of member queues 
when migrating to 1.4 (we've read UPGRADE.txt an added a call-limit to 
all sip peers).
The problem is that the state of the members of the queue sometimes goes 
wrong (members appears as Not in use when they are In use), resulting in 
  dispatching calls to busy agents (we use ringinuse=no for all queues). 
We experienced this in the past in a lab enviroment, and the cause was 
the same: a DNS problem

An analisys showed that Asterisk makes a DNS lookup with the channel 
name, every time a new SIP channel is created. For example, if I've a 
sip peer '151', when making a new channel named SIP/151-b7c317a0, 
asterisk does a DNS query of 151-b7c317a0.localdomain. (localdomain is 
ommited if we have no domain configured at the machine).
Apparently function sip_devicestate is called many times when creating a 
SIP channel, sometimes it hast "SIP/151" as argument (all goes ok in 
that case), and sometimes it is called with entire channel name: 
"SIP/151-b7c317a0", and it is in that case when a DNS query is make, 
because "151-b7c317a0" is not matched in the SIP peer list.

We suffered this problem twice:

1) If we have DNS queries blocked (no response from DNS server), we have 
a delay in propagating the member status, resulting in malfunction 
(delivering calls when members are in use)
2) If DNS server is ok, and response is "Server fail" (some Windows 
servers behave like that), sip_devicestate returns AST_DEVICE_UNKNOWN 
and all fails like before, and queue member state goes wrong, resulting 
in the same chaos.

What is the reason for this DNS query when peer not found in peer list?

I think there are 2 ways to fix this problem:
  1) Not querying a DNS server if peer not found in function 
sip_devicestate, this will elliminate innecesary dns queries.
  2) Not to call to "ast_device_state_changed_literal" (in function 
ast_setstate, channel.c) with ENTIRE channel name, SIP/peer-abcdef

Waiting for your comments.
bye
daniel

--
Ing. Daniel Ferrer
IPContact Software S.R.L.
(+5982) 4025420

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply | 3 comments |
headers
Nguyen Trung Thanh | 18 Aug 12:56

Chan_ss7 use signal and voice in different span of E1

Dear all,

I am use 04E1 card. My SS7 link and voice link to PSTN is assigned with two 
different E1 links. I have tested. An the result is that call establishment 
is ok but no voice.

Plz give me your advices.

Tks & Rgds 

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply | 0 comments |
headers
Tzafrir Cohen | 18 Aug 12:42

asterisk fails to start with bri ptmp timing source

Hi

This is a follow-up to http://bugs.debian.org/491310 . I have recieved a
number of similar reports. Upon further inspection, it seems that all of
them use zaphfc as a Zaptel driver.

While the Debian package in question greatly differs from the main 
Asterisk one (bristuff), the relevant property is supported in main 
Asterisk 1.6 as well: bri ptmp CPE support in chan_dahdi.

BRI ptmp telephony providers tend to keep the line down. And it seems
that most Zaptel card drivers don't provide timing to Zaptel when the
layer 1 is down.

So at least until tose drivers are fixed, if layer 1 does not happen to
be up at the time Asterisk is started, Asterisk will fail to start.

--

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen <at> xorcom.com
+972-50-7952406           mailto:tzafrir.cohen <at> xorcom.com
http://www.xorcom.com  iax:guest <at> local.xorcom.com/tzafrir

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply | 3 comments |
headers
Philipp Kempgen | 18 Aug 02:44

func_logic.c: IMPORT()

The short description of dialplan function IMPORT() in
funcs/func_logic.c (line 209) ends in a "\n" which shouldn't be there.

---cut---
static struct ast_custom_function import_function = {
	.name = "IMPORT",
	.synopsis =
		"Retrieve the value of a variable from another channel\n",
	.syntax = "IMPORT(channel,variable)",
	.read = acf_import,
};
---cut---

-		"Retrieve the value of a variable from another channel\n",
+		"Retrieve the value of a variable from another channel",

trunk, branches/1.6.1, branches/1.6.0

Grüße,
Philipp Kempgen
--

-- 
http://www.das-asterisk-buch.de  -  http://www.the-asterisk-book.com
Amooma GmbH - Bachstr. 126 - 56566 Neuwied  ->  http://www.amooma.de
Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply | 0 comments |
headers
Philipp Kempgen | 17 Aug 21:33

1.6 Privacy()

1.6 UPGRADE.txt:
> * Privacy() no longer uses privacy.conf, so any options must be specified
>   directly in the application arguments.

There is no application named Privacy().
(whereas PrivacyManager() exists)

Grüße,
Philipp Kempgen
--

-- 
http://www.das-asterisk-buch.de  -  http://www.the-asterisk-book.com
Amooma GmbH - Bachstr. 126 - 56566 Neuwied  ->  http://www.amooma.de
Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply | 1 comment |
headers
Philipp Kempgen | 17 Aug 21:20

1.6 SetCallerPres()

1.6 UPGRADE.txt:
> * SetCallerPres() has been replaced with the CALLERPRES() dialplan function
>   and is now deprecated.

"core show application SetCallerPres" doesn't say it's deprecated.

Grüße,
Philipp Kempgen
--

-- 
http://www.das-asterisk-buch.de  -  http://www.the-asterisk-book.com
Amooma GmbH - Bachstr. 126 - 56566 Neuwied  ->  http://www.amooma.de
Geschäftsführer: Stefan Wintermeyer, Handelsregister: Neuwied B14998

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply | 0 comments |
headers
Sean Bright | 17 Aug 16:24

Re: [asterisk-commits] seanbright: branch 1.6.0 r138483 - in /branches/1.6.0: ./ main/features.c

I considered this trivial and non-invasive enough to merge to the 1.6.0
and 1.6.1 branches.  If I should revert, please let me know.

SVN commits to the Asterisk project wrote:
> Author: seanbright
> Date: Sun Aug 17 09:14:46 2008
> New Revision: 138483
> 
> URL: http://svn.digium.com/view/asterisk?view=rev&rev=138483
> Log:
> Merged revisions 138482 via svnmerge from 
> https://origsvn.digium.com/svn/asterisk/trunk
> 
> ........
> r138482 | seanbright | 2008-08-17 10:12:11 -0400 (Sun, 17 Aug 2008) | 6 lines
> 
> Move Uniqueid to the end of the event for those that rely on the position
> of the name/value pairs, pointed out by snuffy-home on #asterisk-commits.
> 
> For those of you who rely on the position of name/value pairs in manager
> events... stop... that is why associative arrays were invented.
> 
> ........
> 
> Modified:
>     branches/1.6.0/   (props changed)
>     branches/1.6.0/main/features.c
> 
> Propchange: branches/1.6.0/
> ------------------------------------------------------------------------------
> Binary property 'trunk-merged' - no diff available.
> 
> Modified: branches/1.6.0/main/features.c
> URL: http://svn.digium.com/view/asterisk/branches/1.6.0/main/features.c?view=diff&rev=138483&r1=138482&r2=138483
> ==============================================================================
> --- branches/1.6.0/main/features.c (original)
> +++ branches/1.6.0/main/features.c Sun Aug 17 09:14:46 2008
> @@ -475,15 +475,16 @@
>  	manager_event(EVENT_FLAG_CALL, "ParkedCall",
>  		"Exten: %s\r\n"
>  		"Channel: %s\r\n"
> -		"Uniqueid: %s\r\n"
>  		"From: %s\r\n"
>  		"Timeout: %ld\r\n"
>  		"CallerIDNum: %s\r\n"
> -		"CallerIDName: %s\r\n",
> -		pu->parkingexten, pu->chan->name, pu->chan->uniqueid, peer ? peer->name : "",
> +		"CallerIDName: %s\r\n"
> +		"Uniqueid: %s\r\n",
> +		pu->parkingexten, pu->chan->name, peer ? peer->name : "",
>  		(long)pu->start.tv_sec + (long)(pu->parkingtime/1000) - (long)time(NULL),
>  		S_OR(pu->chan->cid.cid_num, "<unknown>"),
> -		S_OR(pu->chan->cid.cid_name, "<unknown>")
> +		S_OR(pu->chan->cid.cid_name, "<unknown>"),
> +		pu->chan->uniqueid
>  		);
>  
>  	if (peer && adsipark && ast_adsi_available(peer)) {
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-commits mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-commits

--

-- 
Sean Bright
sean.bright <at> gmail.com

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply | 0 comments |
headers
Sean Bright | 17 Aug 15:00

Asterisk 1.4 with cdr_tds and FreeTDS 0.82

The existing implementation of cdr_tds in Asterisk 1.4 uses libtds,
which is part of the FreeTDS package.  libtds has always been considered
a non-stable API, and developers were encouraged to write their
applications against either the db-lib or ct-lib front end.

With the release of FreeTDS 0.82, libtds is no longer installed by
default, which results in Asterisk's build system not being able to find
FreeTDS and therefore not build the cdr_tds module.

I know that this is not technically a bug in Asterisk, but considering
that we still have users installing the 1.2 series of Asterisk (at their
own peril) I am concerned that users will run into this problem with the
1.4 series for, well, a years.

While I would be satisfied simply documenting that Asterisk 1.4 will not
work with versions of FreeTDS newer than 0.64, the other option is to
move the changes made in trunk (changing cdr_tds to use db-lib) into the
1.4 branch, even though we are feature frozen.  Note that there is no
behavior change in the trunk version, we simply changed which API we
were coding against.

Thoughts?

Thanks,
--

-- 
Sean Bright
sean.bright <at> gmail.com

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
Permalink | Reply | 2 comments |

Gmane