gmane.comp.telephony.pbx.asterisk.devel

[Code Review] logger: Callid logging phase 4: specific changes for chan_local, chan_agent, bridging and autoservice.

jrose — 2012-05-25T19:05:56

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1950/
-----------------------------------------------------------

Review request for Asterisk Developers, Mark Michelson, rmudgett, and Matt Jordan.


Summary
-------

This should be the last set of programming changes.  This review's diff file includes uncommitted changes to dahdi+iax and some other stuff that may be covered by the phase 3 review, but focus should stay on the four things mentioned.


Diffs
-----

  /trunk/channels/chan_agent.c 367420 
  /trunk/channels/chan_dahdi.c 367420 
  /trunk/channels/chan_iax2.c 367420 
  /trunk/channels/chan_local.c 367420 
  /trunk/channels/sig_analog.c 367420 
  /trunk/channels/sig_pri.c 367420 
  /trunk/main/autoservice.c 367420 
  /trunk/main/bridging.c 367420 
  /trunk/main/logger.c 367420 
  /trunk/main/pbx.c 367420 

Diff: https://reviewboard.asterisk.org/r/1950/diff


Testing
-------

Each channel driver was tested to make sure log messages made within related threads would bind properly and the specific channel drivers would also get the right callids referenced.  Bridging api was tested via the confbridge application, and in each case the bridge threads bind to the callid of the channel that started the bridge.  Autoservice was tested via the system dialplan application and threads created by it were similarly bound based on the callid of the channel that started the autoservice.


Thanks,

jrose

--
_____________________________________________________________________

app Swift() hangs

Justin Killen — 2012-05-25T16:09:09

I have and automated call-in dispatch system where hundreds of people call in daily for 2-3 minutes each. The extension is set up to get their information, then text-to-speech the dispatch information (via odbc). It then loops 5 times then ends the call. These calls are being handled by an 8 port analog digium card.
Sometimes though, I see calls via 'core show channel dahdi/1-1' that have a time of > 16 hours.  When a channel gets in this state, the call doesn't seem to progress through the dialplan, they always display the TTS line. Doing a 'dahdi destroy channel 1-1' doesn't seem to be effective - the only way I've been able to clear the calls is to do a 'dahdi restart' and/or restart the asterisk service.
After some investigating and help from the asterisk-users list, problem has been narrowed down to the Swift() app getting stuck (the Swift app is a wrapper around the cepstral text-to-speech engine).
Here is the output from the cli:
dozer*CLI> core show channels
Channel Location State Application(Data)
DAHDI/5-1 s< at >DB_LOOKUP:24 Up Swift(""Schedule for employee
1 active channel
1 active call
1528 calls processed
dozer*CLI> core show channel dahdi/5-1

Digium's new Community Support Manager - Rusty Newton

Kevin P. Fleming — 2012-05-25T14:41:34

We'd like you all to help us welcome Rusty Newton to Digium's Asterisk
development and community support team! Rusty has been with Digium for
over five years, starting in the Technical Support department and then
moving to a sales position where he assisted customers with Asterisk and
Switchvox solutions to their business needs. Prior to joining Digium he
spent more than five years in the telecom industry, installing,
configuring and maintaining PBXs. A couple of weeks ago he moved into a
new role (for him and for Digium), Community Support Manager.

In this role he'll be the primary person responsible for ensuring that
Digium's community services are providing what the community members
need, that the systems are operating properly, and that issues and
questions are getting the attention they deserve. He'll be working
closely with our Community Director as well, especially for events like
AstriCon and others. He works directly with the software development
team at Digium, which will allow him to focus almost exclusively on
technical issues and discussions.

We're quite excited that he has taken on this role and we expect that
you will soon see the benefits of his activities across the community!

[Code Review] Add documentation to function CHANNEL for options echocan_mode and buffers

elguero — 2012-05-25T03:27:52

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1949/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

It looks setting "echocan_mode" and "buffers" through the dialplan was added to chan_dahdi some time ago.  This patch adds some documentation to func_channel.


This addresses bug ASTERISK-19911.
    https://issues.asterisk.org/jira/browse/ASTERISK-19911


Diffs
-----

  /branches/1.8/funcs/func_channel.c 367732 

Diff: https://reviewboard.asterisk.org/r/1949/diff


Testing
-------

Local dev machine.


Thanks,

elguero

--
_____________________________________________________________________

asterisk.org documentation

Paul Belanger — 2012-05-24T22:06:58

Can we please remove the documentation from asterisk.org[1]?  It is old 
an out-dated. New asterisk users are using it and getting frustrated 
when it does not work.

For example, here is what google still returns[2].

[1] http://www.asterisk.org/astdocs/asterisk.html
[2] https://www.google.ca/#q=site:asterisk.org+astdocs

[Code Review] Patch to detect/parse ANI-II / ANI2 / OLI from SIP INVITE messages

Rob Gagnon — 2012-05-24T19:39:29

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1947/
-----------------------------------------------------------

Review request for Asterisk Developers and Rob Gagnon.


Summary
-------

Add ANI2 / OLI parsing for SIP.  The patch checks the "From" header during the handle_request_invite() function for the presence of "isup-oli", "ss7-oli", or "oli" tags.  If present, the up-to-2-digits following the equal sign in the tag are set on the channel's caller structure in the "ani2" int element.

This allows SIP functions that reference ANI2 to work properly for SIP.  Specifically tested was the messaging that occurs when AGI transmits its data to an AGI script.


This addresses bug 19912.
    https://issues.asterisk.org/jira/browse/19912


Diffs
-----

  /trunk/channels/chan_sip.c 367655 

Diff: https://reviewboard.asterisk.org/r/1947/diff


Testing
-------

Call processing via AGI call in dial plan which logs all AGI incoming values was executed from cell phone, land line, and payphone.  During the payphone call, the value of "agi_callingani2" was properly transmitted as "7" while the others were "0"


Thanks,

Rob

--
_____________________________________________________________________

"Sending Complete" IE status availability ?

Pavel Troller — 2012-05-24T19:32:25

Hi!
  I would like to ask, whether it is possible to query the "Sending Complete"
flag status received by the PRI DAHDI channel (in Asterisk 1.8 and above).
  Let's explain better: A SETUP message comes to Asterisk with Called Party
Number digits = 12345. This message MAY contain the Sending Complete IE,
telling, that no more dialling will come, or MAY NOT contain it, in which case
more digits in the overlap mode can be received.
  Is there a chance to query the status of the Sending Complete IE presence
from the dialplan ? Let's imagine that the dialplan contains the _1! extension,
which will be triggered by the above example SETUP message. In the 
extension logic there may be a part which reads more digits in the overlap
mode, but skips the reading in the en-bloc mode (i.e. if the Sending Complete
IE has been received). I didn't find anything relevant on Google, and the only
usage of the flag which I found in sig_pri.c was that presence of this
IE together with zero digits received triggers the "s" extension.
  With regards,
    Pavel

--
_____________________________________________________________________

sqlite3 DB memory leaking?

Stefan Schmidt — 2012-05-24T18:45:39

Hello,

i have an asterisk 1.8 (to be precise dev branch unleash-the-beast)
running since around 11 weeks with sqlite3 db enabled for custome cdr
logging and i can see the master.db file in /var/log/asterisk is
allready 471 MB big. When i do an database show i dont see any entries
in the astdb so i wonder why this file is so big and is still growing up.

the file grows 1024 Byte every minute so i guess there is some kind of
memory leak .

i dont use astdb in my dialplan on any place and there are no registered
sip peers. so for me the output of database show (only two dundi rows)
looks correct to me but i something keeps writing 1 KB every minute into
the master.db file.

if possible i will try to restart asterisk and watch if i can reproduce
this after the restart.

some additional infos about this system:

1125266 calls processed
System uptime: 10 weeks, 6 days, 9 hours, 48 minutes, 34 seconds

HP DL 360G4 with intel xeon quad core 2Ghz, 4 GB ram and doing around
150 concurrent calls in peak.

any ideas what could cause this?

thanks

best regards

stefan

--
_____________________________________________________________________

Reload module

Yaroslav Panych — 2012-05-24T12:23:41

Hi

Is there any possibility to load/unload/reload specific module from
other C module?
Or at least how to run cli command?
I urgently need such routines, because my module periodically updates
some configuration files and must make modules to reread that files.
Realtime configuration is not usable in my case.

regards, Yaroslav

--
_____________________________________________________________________

[Code Review] Help mitigate reinvite glares in theSIP channel driver

Mark Michelson — 2012-05-23T22:46:27

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1946/
-----------------------------------------------------------

Review request for Asterisk Developers.

Summary
-------

There are times where multiple Asterisk servers are peered together over SIP. In such situations, it is possible for both Asterisk servers to attempt to send direct media reinvites to each other simultaneously. This results in a glare situation in which each of the Asterisk servers sends a 491 to the other. After a waiting period, the reinvites are re-attempted. This waiting period can potentially be distracting since it can cause the media to take multiple seconds to finalize, especially if more than 2 Asterisk servers are involved.

This patch introduces a new SIP peer option called "directmedia_outgoing". If enabled, then when communicating with the peer, Asterisk will only attempt to send reinvites if the call direction is outgoing. The assumption is that the peer Asterisk server will also have this setting enabled. This way, when the two Asterisk servers communicate, they will never attempt to send direct media reinvites to each other. Instead, it will always be the peer that placed the call that will send the direct media reinvite.

Diffs
-----

/trunk/channels/chan_sip.c 367417
/trunk/channels/sip/include/sip.h 367417
/trunk/configs/sip.conf.sample 367417

Diff: https://reviewboard.asterisk.org/r/1946/diff

Testing
-------

I have tested this by running two Asterisk servers and ensuring that the option was honored and that the media streams were still set up properly.

Thanks,

Mark

--
_____________________________________________________________________

[Code Review] Add unique message IDs to IMAPvoicemail

Mark Michelson — 2012-05-23T20:46:14

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1945/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

This review has two main parts to it.

1) IMAP voicemail storage now supports unique message IDs like the other storage backends.
2) Old IMAP voicemails that do not have a unique message ID can be updated to have one now. This involves deleting the old message, creating a new one, and then storing that message in the appropriate folder. Comments in the code explain what is going on.


Diffs
-----

  /team/mmichelson/trunk-digiumphones/apps/app_voicemail.c 367360 

Diff: https://reviewboard.asterisk.org/r/1945/diff


Testing
-------

Admittedly, this has only undergone a compilation test.


Thanks,

Mark

--
_____________________________________________________________________

Planned service outage for community services

Asterisk Development Team — 2012-05-23T14:44:44

On May 31, 2012 from approximately 9:00AM to 12:00PM (Central Daylight 
Time, GMT-5), the servers that Digium uses to provide many services to 
the Asterisk community will be relocated. This will mean that these 
services will be unavailable during most, if not all, of this time 
window. Once the move is complete, the services will be available again, 
with no user-visible changes.

The services affected include:

bamboo.asterisk.org
code.asterisk.org
downloads.digium.com
downloads.asterisk.org
git.asterisk.org
issues.asterisk.org
packages.asterisk.org
reviewboard.asterisk.org
svn.asterisk.org
svnview.digium.com
wiki.asterisk.org

--
_____________________________________________________________________

[Code Review] Remove AST_FLAG_ANSWERED_ELSEWHERE, duplicating the functionality of AST_CAUSE_ANSWERED_ELSEWHERE

Birger Harzenetter — 2012-05-23T13:38:26

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1944/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

While 'real' channels use AST_CAUSE_ANSWERED_ELSEWHERE, local channels and queues use AST_FLAG_ANSWERED_ELSEWHERE for the same purpose.
This patch replaces all occurrences of the flag by the cause code, removing the duplicated functionality and the flag itself.


Diffs
-----


Diff: https://reviewboard.asterisk.org/r/1944/diff


Testing
-------


Thanks,

Birger

--
_____________________________________________________________________

[Code Review] Update a peer's lastmsgssent valueappropriately

Matt Jordan — 2012-05-22T17:22:05

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1939/
-----------------------------------------------------------

Review request for Asterisk Developers and irroot.

Summary
-------

In prior versions of Asterisk, the lastmsgssent value was used to track whether or not a peer had received MWI notifications. Since chan_sip polled for the notifications itself, the value was rather important. When MWI notifications were changed to use the event notification framework, the value was no longer useful for anything other then reporting through the CLI or AMI events.

Hence, in Asterisk 10 and trunk, the value was completely removed. Unfortunately, in Asterisk 1.8, the value was not removed; instead, it is set to a value of -1 and never updated. Since the lower 16 bits are used for old messages and the upper 16 bits are used for new messages, this results in the following being displayed for 'sip show peer foo':

LastMsgsSent : 32767/65535

Normally, I'd suggest that we remove the field from Asterisk 1.8 and call it a day. However, since this field was supplied to users via AMI and the CLI, doing so breaks backwards compatibility.

This patch is a modification of a patch originally supplied by irroot on ASTERIS-17866. It re-implements updating of lastmsgssent when an MWI notification is sent to a SIP peer. Note that the original patch had to be modified slightly due to changes in sip_send_mwi_to_peer (and that up to three threads can be involved in accessing lastmsgssent means that, at the very least, the peer really should be locked when we update it).

If we decide that this isn't worth it, we should instead remove the field from Asterisk 1.8, as reporting an erroneous value isn't terribly useful.

This addresses bug ASTERISK-17866.
https://issues.asterisk.org/jira/browse/ASTERISK-17866

Diffs
-----

/branches/1.8/channels/chan_sip.c 367134

Diff: https://reviewboard.asterisk.org/r/1939/diff

Testing
-------

Tested with two SIP realtime peers. One peer without voicemail continued to display the 32767/65535 value - which is expected, as that value indicates that we haven't sent any message notifications. Another peer, with voicemail, correctly showed the new/old message counts post registration, and displayed the counts correctly after MWI notifications were sent when new voicemails were left or listened to.

Thanks,

Matt

--
_____________________________________________________________________

Maximum allowed/recommended size of AMI action?

Yaroslav Panych — 2012-05-22T14:51:01

Hi

Developing my custom AMI action for Asterisk. This action intended to
process relatively big block of data(a few KBs)  received as parameter
in action.  So natural question: how long blocks of data I can send
with action and Asterisk will not suffer any side-effects? Or I should
serialise data transfer using separate action?
Tried to search in source  - found only limitation for number of
headers in action - up to 128. But no total size.

Any ideas?

regards, Yaroslav

--
_____________________________________________________________________

Urgent development consultancy wanted

Alistair Cunningham — 2012-05-22T11:44:34

We have a customer running Asterisk 1.8.7.1 who is suffering from stuck 
calls. The scenario is:

1. A call comes in from the PSTN via SIP.
2. We do a Dial() to a local channel.
3. In the local channel, we do a Dial() to a SIP URI which is a phone 
registered to OpenSIPS on a different machine.
4. The phone rings (and perhaps answers).
5. The caller hangs up.
6. Sometimes one of the channels (either the inbound channel or the 
local channel) never gets hung up, the "h" extension never gets called 
for it, and the channel remains in "core show channels" until Asterisk 
is restarted.

We're looking for a developer who is able to debug this urgently, 
preferably today. If anyone is available and has expertise at debugging 
this problem, please email me off-list with details of exactly when 
you're available, and of course your hourly rate.

[Code Review] Add tests for the IAX2 implementationof the HANGUPCAUSE hash

opticron — 2012-05-21T21:10:57

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1942/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

This tests that the proper hangup information is provided across local channels and when dials are branched.


This addresses bug SWP-4223.
    https://issues.asterisk.org/jira/browse/SWP-4223


Diffs
-----

  asterisk/trunk/tests/iax2/hangupcause/configs/ast1/extensions.conf PRE-CREATION 
  asterisk/trunk/tests/iax2/hangupcause/configs/ast1/iax.conf PRE-CREATION 
  asterisk/trunk/tests/iax2/hangupcause/configs/ast2/extensions.conf PRE-CREATION 
  asterisk/trunk/tests/iax2/hangupcause/configs/ast2/iax.conf PRE-CREATION 
  asterisk/trunk/tests/iax2/hangupcause/run-test PRE-CREATION 
  asterisk/trunk/tests/iax2/hangupcause/test-config.yaml PRE-CREATION 
  asterisk/trunk/tests/iax2/tests.yaml 3229 

Diff: https://reviewboard.asterisk.org/r/1942/diff


Testing
-------

It's a test.  It tests.


Thanks,

opticron

--
_____________________________________________________________________

[Code Review] Add IAX2 support for the newHANGUPCAUSE hash

opticron — 2012-05-21T21:10:51

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1941/
-----------------------------------------------------------

Review request for Asterisk Developers.


Summary
-------

Add the IAX2 implementation of the "Who Hung Up?" work for Asterisk 11.  Numeric cause codes are provided for messages in which they're expected.  Additionally, methods of generating descriptions of frame types and subclasses have been exposed.


This addresses bug SWP-4222.
    https://issues.asterisk.org/jira/browse/SWP-4222


Diffs
-----

  trunk/channels/chan_iax2.c 367194 
  trunk/include/asterisk/frame.h 367194 
  trunk/main/frame.c 367194 

Diff: https://reviewboard.asterisk.org/r/1941/diff


Testing
-------

See tests in Review 1942.


Thanks,

opticron

--
_____________________________________________________________________

[Code Review] Don't use a variable after callingASTOBJ_UNREF on it.

Terry Wilson — 2012-05-21T20:52:47

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1940/
-----------------------------------------------------------

Review request for Asterisk Developers and Matt Jordan.


Summary
-------

This just saves the ref to a variable and unrefs that instead.


This addresses bug ASTERISK-19827.
    https://issues.asterisk.org/jira/browse/ASTERISK-19827


Diffs
-----

  /branches/1.8/channels/chan_sip.c 367176 

Diff: https://reviewboard.asterisk.org/r/1940/diff


Testing
-------

Compiles.


Thanks,

Terry

--
_____________________________________________________________________

Add ability to set up a header (via SIPAddHeader) toProgress()

Konstantin M. — 2012-05-19T21:40:42

Hi,

Could you please implement an ability to set up a header (via SIPAddHeader)
to Progress() ?
For some reasons I need a custom header in 183...

Thanks,
--
_____________________________________________________________________

[Code Review] Start a library of common SIPpscenarios for the testsuite

Mark Michelson — 2012-05-18T20:28:21

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1929/
-----------------------------------------------------------

Review request for Asterisk Developers.

Summary
-------

When writing tests, I find that SIPp scenarios are a common need. My typical method of starting a new scenario is to either

1. Dump the default "uac" or "uas" scenario using sipp -sd and then tweak it to suit my needs or
2. Try to find an existing test that likely has a scenario like what I would need and tweak that to suit my needs.

This aims to begin a library of commonly-needed SIPp scenarios, so that writing tests can be quicker and easier. I have also included a table_of_contents text file that has brief explanations for the scenarios and how they are used. The table_of_contents can be added to when new scenarios are added to the library. There is probably a better method of cataloging the tests than a text file, but I just wanted to get something together to show off for the review.

Let me know what you think. I know there are a bunch of scenario types that are not currently represented (such as anything requiring authentication or tests that use direct media). What I'm more interested in at the moment is if the concept is good and if this would be welcome to the testsuite.

Diffs
-----

/asterisk/trunk/contrib/sipp/calls/uac-blind-transfer.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/calls/uac-hangup.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/calls/uac-no-hangup.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/calls/uas-blind-transfer.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/calls/uas-hangup.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/calls/uas-no-hangup.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/calls/uas-redirect.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/registration/uac-register.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/registration/uac-unregister.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/subscription/uac-subscribe-no-unsubscribe.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/subscription/uac-subscribe-unsubscribe.xml PRE-CREATION
/asterisk/trunk/contrib/sipp/table_of_contents PRE-CREATION

Diff: https://reviewboard.asterisk.org/r/1929/diff

Testing
-------

The scenarios included in this review are either already in use in the test suite or are modified versions (to be more generic) of scenarios already in the testsuite. Therefore, the scenarios have no issues as written.

Thanks,

Mark

--
_____________________________________________________________________