Re: [asterisk-dev] [Code Review] 4178: res_pjsip_outbound_publish: stack overflow when using non-default sorcery wizard

[Kevin Harwell]

> On Nov. 15, 2014, 9:22 a.m., Matt Jordan wrote:
> > branches/13/res/res_pjsip_outbound_publish.c, lines 274-275
> > 
> >
> > I don't really like the pattern that we have here.
> > 
> > We technically have two destructor functions:
> >  * sip_outbound_publish_client_destroy, which destroys the state object
> >  * destroy_old_state, which must only be called on a state object once 
> > just prior to it being destroyed
> > 
> > That feels wrong. I would expect that destroy_old_state should just be 
> > a part of sip_outbound_publish_client_destroy.
> > 
> > If sip_outbound_publish_client_destroy actually is the only destructor 
> > for the object, *and* the container holds the last reference for the object 
> > (assuming it isn't being used elsewhere, in which case reference counting 
> > will still work just fine), the you should be able to just destroy the 
> > container. That will remove the container's reference to its objects, which 
> > will cause their destruction.

The problem that I ran into is that pjsip_publishc object holds a reference to 
the state until unpublish is called.  This means the state destructor won't get 
called until after "unpublishing".  "destroy_old_state" is perhaps a bad name 
for this function.  I'll rename it to something more appropriate like 
cancel_and_unpublish since that is the intent and add comments to make it more 
clear.  Reading this part of the code will then make more sense: Old states no 
longer in use (the config object has been deleted for instance) are cancelled 
and unpublished (state ref dec held by pjsip_publishc) and then removed from 
the memory container (state ref dec on old_states container).

The only other way this might work is by adding a wrapper around the state 
object.  This wrapper is stored in the ao2_container and then when it gets 
destroyed cancel and unpublish on its associated state gets called thus 
releasing the state object.  Thoughts?


- Kevin


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


On Nov. 13, 2014, 2:08 p.m., Kevin Harwell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4178/
> ---
> 
> (Updated Nov. 13, 2014, 2:08 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24514
> https://issues.asterisk.org/jira/browse/ASTERISK-24514
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When using a non-default sorcery wizard (in this instance realtime) for 
> outbound publishes Asterisk will crash after a stack overflow occurs due to 
> the code infinitely recursing.  The fix entails removing the outbound publish 
> state dependency from the outbound publish sorcery object and instead keeping 
> an in memory container that can be used to lookup the state when needed.
> 
> 
> Diffs
> -
> 
>   branches/13/res/res_pjsip_outbound_publish.c 427787 
> 
> Diff: https://reviewboard.asterisk.org/r/4178/diff/
> 
> 
> Testing
> ---
> 
> On top of running the current testsuite tests I also manually tested various 
> configurations and scenarios using a static configuration file as well as 
> dynamic realtime.  Verified that the crash no longer occurs and the 
> potentially affected functionality works as expected (for instance, module 
> [re]loading).
> 
> 
> Thanks,
> 
> Kevin Harwell
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4192: Update channel Stasis topics during a masquerade

[Mark Michelson]

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

(Updated Nov. 18, 2014, 10:04 p.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers and opticron.


Repository: Asterisk


Description
---

Testing revealed a regression that occurred when performing an attended 
transfer to a Stasis application. StasisEnd events were not being seen for the 
channels involved in the masquerade that occurs in this situation.

In the test, a channel not in a is attended transferred into a Stasis 
application. When performing an attended transfer into an application, a 
masquerade is required. The transferee channel takes the place of the channel 
that previously was in the Stasis application. The masquerade operation calls 
into Stasis, stating that a channel in Stasis is being replaced by a channel 
that was previously not in Stasis. The expected outcome is that the channel 
that previously was not in Stasis will have all its events sent to the Stasis 
application. The problem is that the masquerade operation, while updating the 
internals of the involved channels, never actually updates the Stasis channel 
topics on the involved channels. The result is that forwards from an incorrect 
channel topic are going to the interested Stasis application, which don't match 
up with what the Stasis app thinks it is interested in. By updating the topic 
on the channel prior to calling masquerade fixup/breakdown callbacks, the f
 orwards work as expected and StasisEnd messages reach the application as 
expected.


Diffs
-

  /branches/12/main/channel_internal_api.c 428116 
  /branches/12/main/channel.c 428116 

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


Testing
---

Re-ran the attended transfer test that had been failing and found that it 
worked consistently.


Thanks,

Mark Michelson

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

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

Re: [asterisk-dev] [Code Review] 4172: Testsuite: tests for res_pjsip_config_wizard

[Matt Jordan]

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

Ship it!


- Matt Jordan


On Nov. 18, 2014, 11:40 a.m., George Joseph wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4172/
> ---
> 
> (Updated Nov. 18, 2014, 11:40 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> These are the tests for res_pjsip_config_wizard 
> https://reviewboard.asterisk.org/r/4190/
> 
> When I cloned AMISendTest, I made a small change that might be usefull for 
> other AMI tests...  You now specify the ACTION in test-config.yaml rather 
> than having ACTION hard coded in AMISendTest.py and the results in 
> test-config.yaml.
> 
> 
> Diffs
> -
> 
>   asterisk/trunk/tests/channels/pjsip/tests.yaml 5948 
>   asterisk/trunk/tests/channels/pjsip/config_wizard/trunk/test-config.yaml 
> PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/trunk/configs/ast1/pjsip_wizard.conf
>  PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/trunk/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   asterisk/trunk/tests/channels/pjsip/config_wizard/tests.yaml PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/registration/test-config.yaml
>  PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/registration/configs/ast1/pjsip_wizard.conf
>  PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/registration/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   asterisk/trunk/tests/channels/pjsip/config_wizard/phone/test-config.yaml 
> PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/phone/configs/ast1/pjsip_wizard.conf
>  PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/phone/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   asterisk/trunk/tests/channels/pjsip/config_wizard/AMISendTest.py 
> PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/4172/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> George Joseph
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4145: testsuite: update pretty_print script for recent runtests.py changes.

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On Nov. 16, 2014, 7:38 p.m., George Joseph wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4145/
> ---
> 
> (Updated Nov. 16, 2014, 7:38 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Updated contrib/scripts/pretty_print so it works with recent runtests.py 
> changes.  Also changed it from a filter to a standalone script.
> 
> 
> Diffs
> -
> 
>   asterisk/trunk/runtests.py 5927 
>   asterisk/trunk/contrib/scripts/pretty_print 5927 
> 
> Diff: https://reviewboard.asterisk.org/r/4145/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> George Joseph
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4185: sorcery: Make ast_sorcery_is_object_field_registered handle field names that are regexes.

[George Joseph]

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

(Updated Nov. 18, 2014, 2:18 p.m.)


Review request for Asterisk Developers, Joshua Colp and Mark Michelson.


Changes
---

Updated testing status.


Bugs: ASTERISK-24520
https://issues.asterisk.org/jira/browse/ASTERISK-24520


Repository: Asterisk


Description
---

As a result of https://reviewboard.asterisk.org/r/3305, res_sorcery_realtime 
was tossing database fields that didn't have an exact match to a sorcery 
registered field.  This broke the ability to use regexes as field names which 
manifested itself as a failure of res_pjsip_phoneprov_provider which uses this 
capability.  It also broke handling of fields that start with '@' in realtime 
but I don't think anyone noticed.

This patch does the following...
Modifies ast_sorcery_fields_register to pre-compile the name regex.
Modifies ast_sorcery_is_object_field_registered to test the regex if it exists 
instead of doing an exact strcmp.
Modifies res_pjsip_phoneprov_provider with a few tweaks to get it to work with 
realtime.


Diffs
-

  branches/12/res/res_pjsip_phoneprov_provider.c 427949 
  branches/12/main/sorcery.c 427949 

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


Testing (updated)
---

Tested by me with realtime phoneprov, aor and registration objects both with 
and without registered objects.
Testsuite testing in progress.  EDIT: complete.  No issues.
Will also be tested by John Kiniston who reported the 
res_pjsip_phoneprov_provider issue.  EDIT: complete.


Thanks,

George Joseph

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

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

Re: [asterisk-dev] [Code Review] 4090: testsuite: add basic valgrind support

[George Joseph]

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


Got a small problem with this...   When runtests.py checks to see if asterisk 
running it does 'pidof asterisk' which doesn't catch anything if asterisk was 
started with valgrind.  If you ctrl-c out of a -V test, valgrind is left 
running and a subsequent runtests.py can't kill it because it doesn't find it.


- George Joseph


On Nov. 18, 2014, 8:49 a.m., Scott Griepentrog wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4090/
> ---
> 
> (Updated Nov. 18, 2014, 8:49 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This adds very basic valgrind support, which is convenient for manual test 
> runs but does not (yet) include support for more automated valgrind usage. 
> 
> 1) CLI flag '-V' enables valgrind (./runtests -V -t tests/test)
> 
> 2) Minimal changes to testsuite, other improvements can be added later if 
> desired
> 
> 3) Valgrind output is picked up by error logging and shown after test run.
> 
> 4) Unlike previous valgrind attempt, this one works fine on tests with 
> multiple asterisk instances
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/runtests.py 5733 
>   /asterisk/trunk/lib/python/asterisk/test_case.py 5733 
>   /asterisk/trunk/lib/python/asterisk/asterisk.py 5733 
> 
> Diff: https://reviewboard.asterisk.org/r/4090/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4194: ast_str: Fix improper member access to struct ast_str members.

[Corey Farrell]

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

Ship it!


Ship It!

- Corey Farrell


On Nov. 18, 2014, 3:03 p.m., rmudgett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4194/
> ---
> 
> (Updated Nov. 18, 2014, 3:03 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Accessing members of struct ast_str outside of the string manipulation API 
> routines is invalid since struct ast_str is supposed to be opaque.
> 
> 
> Diffs
> -
> 
>   /branches/11/res/res_calendar.c 428170 
>   /branches/11/channels/sip/security_events.c 428170 
>   /branches/11/channels/chan_sip.c 428170 
> 
> Diff: https://reviewboard.asterisk.org/r/4194/diff/
> 
> 
> Testing
> ---
> 
> Use of the DEBUG_OPAQUE define no longer produces compile errors with the 
> patch.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

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

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

[asterisk-dev] [Code Review] 4194: ast_str: Fix improper member access to struct ast_str members.

[rmudgett]

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

Accessing members of struct ast_str outside of the string manipulation API 
routines is invalid since struct ast_str is supposed to be opaque.


Diffs
-

  /branches/11/res/res_calendar.c 428170 
  /branches/11/channels/sip/security_events.c 428170 
  /branches/11/channels/chan_sip.c 428170 

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


Testing
---

Use of the DEBUG_OPAQUE define no longer produces compile errors with the patch.


Thanks,

rmudgett

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

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

Re: [asterisk-dev] [Code Review] 3603: func_jitterbuffer: fix audio failure caused by certain masquerade's

[opticron]

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



/branches/11/funcs/func_jitterbuffer.c


These should use ast_strdup and should be checked for failure.


- opticron


On Oct. 30, 2014, 7:06 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3603/
> ---
> 
> (Updated Oct. 30, 2014, 7:06 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp and Matt Jordan.
> 
> 
> Bugs: ASTERISK-22409
> https://issues.asterisk.org/jira/browse/ASTERISK-22409
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> During masquerade it is possible for the AST_JITTERBUFFER_FD to be cleared 
> (set to -1).  This change adds a check when copying channel fd's to prevent 
> clearing an FD with -1.  This seems to resolve the bad audio quality 
> experienced after the masquerade.  When AST_JITTERBUFFER_FD was set to -1, 
> this prevented the channel from polling that timer.  This caused RTP packets 
> to be received late, and discarded.
> 
> 
> Diffs
> -
> 
>   /branches/11/main/channel.c 426593 
>   /branches/11/funcs/func_jitterbuffer.c 426593 
> 
> Diff: https://reviewboard.asterisk.org/r/3603/diff/
> 
> 
> Testing
> ---
> 
> Verified the scenario outlined in ASTERISK-22409 no longer experiences audio 
> quality loss.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4186: stringfields: Fix regression from fix for unintentional memory retention caused by ast_string_fields_copy

[rmudgett]

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

Ship it!


Ship It!

- rmudgett


On Nov. 18, 2014, 12:36 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4186/
> ---
> 
> (Updated Nov. 18, 2014, 12:36 p.m.)
> 
> 
> Review request for Asterisk Developers and rmudgett.
> 
> 
> Bugs: ASTERISK-24535
> https://issues.asterisk.org/jira/browse/ASTERISK-24535
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> ast_string_fields_copy relies on the fact that 
> __ast_string_field_release_active never previously zeroed pool->used, so 
> keeping the existing pointer was "ok".  Setting each field to 
> __ast_string_field_empty after releasing the memory seems to resolve the 
> issue.
> 
> 
> Diffs
> -
> 
>   /branches/12/include/asterisk/stringfields.h 428167 
> 
> Diff: https://reviewboard.asterisk.org/r/4186/diff/
> 
> 
> Testing
> ---
> 
> Full testsuite against 12.  I had 17 failures, but that is normal on my 
> system.  I re-ran the 17 tests without this patch, they still failed.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

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

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

[asterisk-dev] [Code Review] 4193: Stasis: allow for subscriptions to dictate message delivery on a threadpool for certain situations

[Matt Jordan]

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

Review request for Asterisk Developers.


Bugs: ASTERISK-24533
https://issues.asterisk.org/jira/browse/ASTERISK-24533


Repository: Asterisk


Description
---

Note: don't be fooled by the size of this review. Most of the changes are small 
and are in stasis.c/stasis_message_router.c.

Rob (and CDR on the asterisk-users list, although he never followed up when we 
asked for more information) discovered that we were creating two additional 
threads per SIP peer in chan_sip. This actually would occur for a large variety 
of 'endpoints' in Asterisk, regardless of the channel driver. The two threads 
were stasis subscriptions, specifically for MWI and for endpoints detecting the 
destruction of related channels.

Stasis subscriptions currently get a dedicated thread. In contrast, prior to 
r400178 (see review https://reviewboard.asterisk.org/r/2881/), the 
subscriptions shared a thread pool. It was discovered that for a low 
subscription count with high message throughput, the threadpool was not as 
performant as simply having a dedicated thread per subscriber.

Since then, our subscription pattern has changed slightly. While we still have 
plenty of subscriptions that would follow the model just described (AMI, CDRs, 
CEL, etc.) - there are plenty that also fall into the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate a 
single message - the subscription is created, a message is published, the 
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and 
in the case of a large number of peers/endpoints, harmful).

This patch adds the ability of a subscriber to Stasis to choose whether or not 
their messages are dispatched on a dedicated thread or on a threadpool. The 
threadpool is currently hard coded in this patch; if configuration is 
necessary, we could re-add the configuration options in r2881. Pre-mature 
optimization and all that led me to simply go with a simpler model for now.

Note that the approach taken here was to add additional API calls rather than 
modify existing ones. If we'd rather the thread dispatch model be dictated by a 
parameter, the new API calls can be removed in trunk and the old API calls 
modified appropriately.


Diffs
-

  /team/mjordan/12-threadpool/tests/test_stasis.c 428167 
  /team/mjordan/12-threadpool/res/res_xmpp.c 428167 
  /team/mjordan/12-threadpool/res/res_stasis_device_state.c 428167 
  /team/mjordan/12-threadpool/res/res_pjsip_refer.c 428167 
  /team/mjordan/12-threadpool/res/res_pjsip_pubsub.c 428167 
  /team/mjordan/12-threadpool/res/res_pjsip_mwi.c 428167 
  /team/mjordan/12-threadpool/res/res_jabber.c 428167 
  /team/mjordan/12-threadpool/res/parking/parking_bridge_features.c 428167 
  /team/mjordan/12-threadpool/res/parking/parking_applications.c 428167 
  /team/mjordan/12-threadpool/main/stasis_message_router.c 428167 
  /team/mjordan/12-threadpool/main/stasis_channels.c 428167 
  /team/mjordan/12-threadpool/main/stasis_cache.c 428167 
  /team/mjordan/12-threadpool/main/stasis.c 428167 
  /team/mjordan/12-threadpool/main/endpoints.c 428167 
  /team/mjordan/12-threadpool/include/asterisk/stasis_message_router.h 428167 
  /team/mjordan/12-threadpool/include/asterisk/stasis_internal.h 428167 
  /team/mjordan/12-threadpool/include/asterisk/stasis.h 428167 
  /team/mjordan/12-threadpool/channels/sig_pri.c 428167 
  /team/mjordan/12-threadpool/channels/chan_skinny.c 428167 
  /team/mjordan/12-threadpool/channels/chan_sip.c 428167 
  /team/mjordan/12-threadpool/channels/chan_mgcp.c 428167 
  /team/mjordan/12-threadpool/channels/chan_iax2.c 428167 
  /team/mjordan/12-threadpool/channels/chan_dahdi.c 428167 

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


Testing
---

New unit tests were written to cover the new subscription types. This tests 
receiving messages sent using the threadpool.

The MWI tests and channel driver tests in the Test Suite were run and passed.


Thanks,

Matt Jordan

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

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

Re: [asterisk-dev] [Code Review] 4186: stringfields: Fix regression from fix for unintentional memory retention caused by ast_string_fields_copy

[Corey Farrell]

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

(Updated Nov. 18, 2014, 1:36 p.m.)


Review request for Asterisk Developers and rmudgett.


Changes
---

Fix description


Bugs: ASTERISK-24535
https://issues.asterisk.org/jira/browse/ASTERISK-24535


Repository: Asterisk


Description (updated)
---

ast_string_fields_copy relies on the fact that 
__ast_string_field_release_active never previously zeroed pool->used, so 
keeping the existing pointer was "ok".  Setting each field to 
__ast_string_field_empty after releasing the memory seems to resolve the issue.


Diffs
-

  /branches/12/include/asterisk/stringfields.h 428167 

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


Testing
---

Full testsuite against 12.  I had 17 failures, but that is normal on my system. 
 I re-ran the 17 tests without this patch, they still failed.


Thanks,

Corey Farrell

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

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

Re: [asterisk-dev] [Code Review] 4186: stringfields: Fix regression from fix for unintentional memory retention caused by ast_string_fields_copy

[Corey Farrell]

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

(Updated Nov. 18, 2014, 1:33 p.m.)


Review request for Asterisk Developers and rmudgett.


Changes
---

Update patch to remove change that had no effect.  Update title/branches.


Summary (updated)
-

stringfields: Fix regression from fix for unintentional memory retention caused 
by ast_string_fields_copy


Bugs: ASTERISK-24535
https://issues.asterisk.org/jira/browse/ASTERISK-24535


Repository: Asterisk


Description
---

This addresses a regression in the previous fix that applies to all versions.  
When __ast_string_field_ptr_grow is called by 
ast_string_field_ptr_set_by_fields, it needs to be passed &target, not __p__.  
In the current code if __ast_string_field_ptr_grow actually does anything, it 
will cause *__p__ != target.  Unfortunately in this case *__p__ points to the 
new address, target to the old.  This may cause too much data to be written to 
the old space for the string, and this could cause memory corruption.  This was 
the first thing I noticed when attempting to troubleshoot 
res/parking/dynamic_parking_variables unit test failure, but did not fix the 
test.

Also needed to get the unit test working again is a fix for 
ast_string_fields_copy in 12+.  The existing code relies on the fact that 
__ast_string_field_release_active never previously zeroed pool->used, so 
keeping the existing pointer was ok.  Setting each field to 
__ast_string_field_empty after releasing the memory seems to resolve the issue.


Diffs (updated)
-

  /branches/12/include/asterisk/stringfields.h 428167 

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


Testing
---

Full testsuite against 12.  I had 17 failures, but that is normal on my system. 
 I re-ran the 17 tests without this patch, they still failed.


Thanks,

Corey Farrell

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

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

Re: [asterisk-dev] [Code Review] 4186: stringfields: Fix regression from fix for unintentional memory retention and another issue exposed by the fix

[Corey Farrell]

> On Nov. 18, 2014, 1:19 p.m., rmudgett wrote:
> > What you have found shows that the problem is in v12+ and not v1.8+

I had thought that the call to __ast_string_field_ptr_grow was a problem in 
1.8/11 based on thinking that 'AST_STRING_FIELD_ALLOCATION(*ptr) += grow;' 
would modify the __p__, but if that's not the case then the only issue I could 
find is with ast_string_fields_copy, which is only in v12+.


- Corey


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


On Nov. 18, 2014, 9:25 a.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4186/
> ---
> 
> (Updated Nov. 18, 2014, 9:25 a.m.)
> 
> 
> Review request for Asterisk Developers and rmudgett.
> 
> 
> Bugs: ASTERISK-24535
> https://issues.asterisk.org/jira/browse/ASTERISK-24535
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This addresses a regression in the previous fix that applies to all versions. 
>  When __ast_string_field_ptr_grow is called by 
> ast_string_field_ptr_set_by_fields, it needs to be passed &target, not __p__. 
>  In the current code if __ast_string_field_ptr_grow actually does anything, 
> it will cause *__p__ != target.  Unfortunately in this case *__p__ points to 
> the new address, target to the old.  This may cause too much data to be 
> written to the old space for the string, and this could cause memory 
> corruption.  This was the first thing I noticed when attempting to 
> troubleshoot res/parking/dynamic_parking_variables unit test failure, but did 
> not fix the test.
> 
> Also needed to get the unit test working again is a fix for 
> ast_string_fields_copy in 12+.  The existing code relies on the fact that 
> __ast_string_field_release_active never previously zeroed pool->used, so 
> keeping the existing pointer was ok.  Setting each field to 
> __ast_string_field_empty after releasing the memory seems to resolve the 
> issue.
> 
> 
> Diffs
> -
> 
>   /branches/12/include/asterisk/stringfields.h 427735 
> 
> Diff: https://reviewboard.asterisk.org/r/4186/diff/
> 
> 
> Testing
> ---
> 
> Full testsuite against 12.  I had 17 failures, but that is normal on my 
> system.  I re-ran the 17 tests without this patch, they still failed.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4186: stringfields: Fix regression from fix for unintentional memory retention and another issue exposed by the fix

[rmudgett]

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


What you have found shows that the problem is in v12+ and not v1.8+


/branches/12/include/asterisk/stringfields.h


This change doesn't have any effect.  __ast_string_field_ptr_grow() grows 
the reserved string space at __p__ only if __p__ is the last string in the pool 
memory block.  It does not change the string pointer itself.

01234567890123456789
..^...A
*__p__ points to position 2 with a reserved space of 5 characters starting 
at position 2 and ending as indicated by A
after
01234567890123456789
..^..A
*__p__ still points to position 2 but with a reserved space of 8 characters 
starting at position 2 and ending as indicated by A



- rmudgett


On Nov. 18, 2014, 8:25 a.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4186/
> ---
> 
> (Updated Nov. 18, 2014, 8:25 a.m.)
> 
> 
> Review request for Asterisk Developers and rmudgett.
> 
> 
> Bugs: ASTERISK-24535
> https://issues.asterisk.org/jira/browse/ASTERISK-24535
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This addresses a regression in the previous fix that applies to all versions. 
>  When __ast_string_field_ptr_grow is called by 
> ast_string_field_ptr_set_by_fields, it needs to be passed &target, not __p__. 
>  In the current code if __ast_string_field_ptr_grow actually does anything, 
> it will cause *__p__ != target.  Unfortunately in this case *__p__ points to 
> the new address, target to the old.  This may cause too much data to be 
> written to the old space for the string, and this could cause memory 
> corruption.  This was the first thing I noticed when attempting to 
> troubleshoot res/parking/dynamic_parking_variables unit test failure, but did 
> not fix the test.
> 
> Also needed to get the unit test working again is a fix for 
> ast_string_fields_copy in 12+.  The existing code relies on the fact that 
> __ast_string_field_release_active never previously zeroed pool->used, so 
> keeping the existing pointer was ok.  Setting each field to 
> __ast_string_field_empty after releasing the memory seems to resolve the 
> issue.
> 
> 
> Diffs
> -
> 
>   /branches/12/include/asterisk/stringfields.h 427735 
> 
> Diff: https://reviewboard.asterisk.org/r/4186/diff/
> 
> 
> Testing
> ---
> 
> Full testsuite against 12.  I had 17 failures, but that is normal on my 
> system.  I re-ran the 17 tests without this patch, they still failed.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

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

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

[asterisk-dev] [Code Review] 4192: Update channel Stasis topics during a masquerade

[Mark Michelson]

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

Review request for Asterisk Developers and opticron.


Repository: Asterisk


Description
---

Testing revealed a regression that occurred when performing an attended 
transfer to a Stasis application. StasisEnd events were not being seen for the 
channels involved in the masquerade that occurs in this situation.

In the test, a channel not in a is attended transferred into a Stasis 
application. When performing an attended transfer into an application, a 
masquerade is required. The transferee channel takes the place of the channel 
that previously was in the Stasis application. The masquerade operation calls 
into Stasis, stating that a channel in Stasis is being replaced by a channel 
that was previously not in Stasis. The expected outcome is that the channel 
that previously was not in Stasis will have all its events sent to the Stasis 
application. The problem is that the masquerade operation, while updating the 
internals of the involved channels, never actually updates the Stasis channel 
topics on the involved channels. The result is that forwards from an incorrect 
channel topic are going to the interested Stasis application, which don't match 
up with what the Stasis app thinks it is interested in. By updating the topic 
on the channel prior to calling masquerade fixup/breakdown callbacks, the f
 orwards work as expected and StasisEnd messages reach the application as 
expected.


Diffs
-

  /branches/12/main/channel_internal_api.c 428116 
  /branches/12/main/channel.c 428116 

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


Testing
---

Re-ran the attended transfer test that had been failing and found that it 
worked consistently.


Thanks,

Mark Michelson

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

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

Re: [asterisk-dev] [Code Review] 4172: Testsuite: tests for res_pjsip_config_wizard

[George Joseph]

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

(Updated Nov. 18, 2014, 10:40 a.m.)


Review request for Asterisk Developers.


Changes
---

Updated for Matt's comments and separated config into pjsip.conf and 
pjsip_wizard.conf.


Repository: testsuite


Description (updated)
---

These are the tests for res_pjsip_config_wizard 
https://reviewboard.asterisk.org/r/4190/

When I cloned AMISendTest, I made a small change that might be usefull for 
other AMI tests...  You now specify the ACTION in test-config.yaml rather than 
having ACTION hard coded in AMISendTest.py and the results in test-config.yaml.


Diffs (updated)
-

  asterisk/trunk/tests/channels/pjsip/tests.yaml 5948 
  asterisk/trunk/tests/channels/pjsip/config_wizard/trunk/test-config.yaml 
PRE-CREATION 
  
asterisk/trunk/tests/channels/pjsip/config_wizard/trunk/configs/ast1/pjsip_wizard.conf
 PRE-CREATION 
  
asterisk/trunk/tests/channels/pjsip/config_wizard/trunk/configs/ast1/pjsip.conf 
PRE-CREATION 
  asterisk/trunk/tests/channels/pjsip/config_wizard/tests.yaml PRE-CREATION 
  
asterisk/trunk/tests/channels/pjsip/config_wizard/registration/test-config.yaml 
PRE-CREATION 
  
asterisk/trunk/tests/channels/pjsip/config_wizard/registration/configs/ast1/pjsip_wizard.conf
 PRE-CREATION 
  
asterisk/trunk/tests/channels/pjsip/config_wizard/registration/configs/ast1/pjsip.conf
 PRE-CREATION 
  asterisk/trunk/tests/channels/pjsip/config_wizard/phone/test-config.yaml 
PRE-CREATION 
  
asterisk/trunk/tests/channels/pjsip/config_wizard/phone/configs/ast1/pjsip_wizard.conf
 PRE-CREATION 
  
asterisk/trunk/tests/channels/pjsip/config_wizard/phone/configs/ast1/pjsip.conf 
PRE-CREATION 
  asterisk/trunk/tests/channels/pjsip/config_wizard/AMISendTest.py PRE-CREATION 

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


Testing
---


Thanks,

George Joseph

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

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

[asterisk-dev] [Code Review] 4190: res_pjsip_config_wizard: Allow streamlined configuration of common pjsip scenarios

[George Joseph]

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

Review request for Asterisk Developers, Joshua Colp and Mark Michelson.


Repository: Asterisk


Description
---

The PJSIP Configuration Wizard allows for creation of simple pjsip scenarios 
like phone or trunk without having to directly specify individual endpoints, 
aors, auths, identifies or registrations.  The easiest way to demonstrate this 
is with an example or two from pjsip_wizard.conf.sample...

;EXAMPLE WIZARD CONFIGURATION FOR A PHONE===

; This config would create an endpoint, aor with dynamic contact, inbound
; auth and a phoneprov object.

[myphone]
type = wizard
accepts_auth = yes
accepts_registrations = yes
transport = ipv4
aor/max_contacts = 1
inbound_auth/username = testname
inbound_auth/password = test password
endpoint/allow = ulaw
endpoint/context = default
phoneprov/MAC = 001122aa4455
phoneprov/PROFILE = profile1

;EXAMPLE WIZARD CONFIGURATION FOR AN ITSP TRUNK=

; This ITSP has 2 servers available and requires registration.

; This config would create an endpoint, an aor with 2 static contacts, an 
outbound
; auth, an identify with 2 matches, and 2 registrations.

[mytrunk]
type = wizard
sends_auth = yes
sends_registrations = yes
transport = ipv4
; The number of remote_hosts drives the number of contacts, matches and 
registrations.
remote_hosts = sip1.myitsp.com:5060,sip2.myitsp.com:5060
outbound_auth/username = testname
outbound_auth/password = test password
endpoint/allow = ulaw
endpoint/context = default

pjsip_wizard.conf.sample has more details.

The history of the wizard approach can be found in the following 2 threads...

http://lists.digium.com/pipermail/asterisk-dev/2014-September/070426.html
http://lists.digium.com/pipermail/asterisk-dev/2014-October/070616.html

THEORY OF OPERATION:

N.B.:  The term 'wizard' is used in 2 contexts here.  This module implements a 
sorcery wizard similar to res_sorcery_config and provides the functionality for 
the PJSIP Configuration Wizard.

The wizard is implemented in a single module but did require a few tweaks to 
other res_pjsip modules and sorcery itself.  There are 2 parts to this module, 
the config wizard and the sorcery wizard.  When the module loads, it registers 
itself as a sorcery wizard which is implemented in the bottom half of 
res_pjsip_config_wizard.c.  When sorcery calls the wizard's load and reload 
functions for a specific pjsip object type, the wizard parses through the 
pjsip_wizard.conf file and creates the appropriate object for each 'wizard' 
type.  For example, if asked to load endpoints, the wizard will parse 
pjsip_wizard.conf and create an endpoint for each 'wizard' type in the file.  
This process happens AFTER objects are read from sources defined in 
sorcery.conf and pjsip.conf.  In the end, the pjsip stack is none the wiser 
about where the objects came from and all AMI, ARI, CLI etc. operate as normal. 
 The only way to differentiate between objects created discretely and those 
created by the wiza
 rd is that the wizard-created ones will all have an extended attribute named 
'@pjsip_wizard' with a value of the wizard id.

SUMMARY OF CHANGES MADE:

* The new res_pjsip_config_wizard module was created.
* An existing internal sorcery api was exposed as 
ast_sorcery_apply_wizard_mapping to allow the addition of a new wizard to an 
object type.  The underlying plumbing was already there.
* config_auth, location, pjsip_configuration, res_pjsip_endpoint_identifier_ip, 
res_pjsip_outbound_registration and res_pjsip_phoneprov_provider were all 
modified to call ast_sorcery_apply_wizard_mapping after calling 
ast_sorcery_apply_default.
* res_pjsip_phoneprov_provider needed a little more work to be compatible.
* During troubleshooting I realized that there were no 'pjsip show identify' 
commands so I added them to res_pjsip_endpoint_identifier.  I also plugged an 
existing  CLI reference leak.

RELOADABILITY:

The new module itself cannot be reloaded or unloaded but there's no point to 
that anyway.  It would just unregister as a sorcery wizard and re-register.  
'core reload' and 'module reload res_pjsip' work quite well though which is 
much more important.  'core reload' is the preferred reload mechanism over 
reloading specific pjsip modules because it reloads all modules so modules such 
as res_pjsip_outbound_registration know to start registration for newly 
discovered objects.  

BACKWARDS COMPATIBILITY:

This module does not change any existing functionality.  Once created by the 
wizard, pjsip objects are indistinguishable from ones created discretely other 
than the addition of the '@pjsip_wizard' attribute.

OTHER:

This module does not use sorcery to read its pjsip_wizard.conf file.  Since 
this module implements a sor

Re: [asterisk-dev] [Code Review] 4187: res_pjsip_refer: Ensure Refer-To is NULL terminated and parse it as a URI

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On Nov. 16, 2014, 5:36 p.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4187/
> ---
> 
> (Updated Nov. 16, 2014, 5:36 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24508
> https://issues.asterisk.org/jira/browse/ASTERISK-24508
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Currently when parsing the Refer-To header there is no guarantee that it will 
> be NULL terminated. It is also parsed as a 'To' header when in reality it 
> should be parsed as a URI as parsing as a 'To' header may sometimes 
> (seemingly) fail. This change fixes both.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip_refer.c 427708 
> 
> Diff: https://reviewboard.asterisk.org/r/4187/diff/
> 
> 
> Testing
> ---
> 
> Did transfers, confirmed they still work.
> 
> Provided patch to reporter and they confirmed it fixed the issue.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4187: res_pjsip_refer: Ensure Refer-To is NULL terminated and parse it as a URI

[Matt Jordan]

> On Nov. 18, 2014, 10:44 a.m., Matt Jordan wrote:
> > /branches/12/res/res_pjsip_refer.c, lines 876-884
> > 
> >
> > Why is it safe to modify the refer_to->hvalue.ptr directly? I would 
> > have thought we'd have to allocate a buffer and copy the header before 
> > manipulating it.
> 
> Joshua Colp wrote:
> Nothing else will use the message and the ownership is with us until we 
> return. Not gonna lie though - I copied it from PJSIP code. I can copy it 
> from the pool and have it be NULL terminated.

If that's the case, then I don't see any reason to change it.


- Matt


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


On Nov. 16, 2014, 5:36 p.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4187/
> ---
> 
> (Updated Nov. 16, 2014, 5:36 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24508
> https://issues.asterisk.org/jira/browse/ASTERISK-24508
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Currently when parsing the Refer-To header there is no guarantee that it will 
> be NULL terminated. It is also parsed as a 'To' header when in reality it 
> should be parsed as a URI as parsing as a 'To' header may sometimes 
> (seemingly) fail. This change fixes both.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip_refer.c 427708 
> 
> Diff: https://reviewboard.asterisk.org/r/4187/diff/
> 
> 
> Testing
> ---
> 
> Did transfers, confirmed they still work.
> 
> Provided patch to reporter and they confirmed it fixed the issue.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4187: res_pjsip_refer: Ensure Refer-To is NULL terminated and parse it as a URI

[Joshua Colp]

> On Nov. 18, 2014, 4:44 p.m., Matt Jordan wrote:
> > /branches/12/res/res_pjsip_refer.c, lines 876-884
> > 
> >
> > Why is it safe to modify the refer_to->hvalue.ptr directly? I would 
> > have thought we'd have to allocate a buffer and copy the header before 
> > manipulating it.

Nothing else will use the message and the ownership is with us until we return. 
Not gonna lie though - I copied it from PJSIP code. I can copy it from the pool 
and have it be NULL terminated.


- Joshua


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


On Nov. 16, 2014, 11:36 p.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4187/
> ---
> 
> (Updated Nov. 16, 2014, 11:36 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24508
> https://issues.asterisk.org/jira/browse/ASTERISK-24508
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Currently when parsing the Refer-To header there is no guarantee that it will 
> be NULL terminated. It is also parsed as a 'To' header when in reality it 
> should be parsed as a URI as parsing as a 'To' header may sometimes 
> (seemingly) fail. This change fixes both.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip_refer.c 427708 
> 
> Diff: https://reviewboard.asterisk.org/r/4187/diff/
> 
> 
> Testing
> ---
> 
> Did transfers, confirmed they still work.
> 
> Provided patch to reporter and they confirmed it fixed the issue.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4187: res_pjsip_refer: Ensure Refer-To is NULL terminated and parse it as a URI

[Matt Jordan]

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



/branches/12/res/res_pjsip_refer.c


Why is it safe to modify the refer_to->hvalue.ptr directly? I would have 
thought we'd have to allocate a buffer and copy the header before manipulating 
it.


- Matt Jordan


On Nov. 16, 2014, 5:36 p.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4187/
> ---
> 
> (Updated Nov. 16, 2014, 5:36 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24508
> https://issues.asterisk.org/jira/browse/ASTERISK-24508
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Currently when parsing the Refer-To header there is no guarantee that it will 
> be NULL terminated. It is also parsed as a 'To' header when in reality it 
> should be parsed as a URI as parsing as a 'To' header may sometimes 
> (seemingly) fail. This change fixes both.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip_refer.c 427708 
> 
> Diff: https://reviewboard.asterisk.org/r/4187/diff/
> 
> 
> Testing
> ---
> 
> Did transfers, confirmed they still work.
> 
> Provided patch to reporter and they confirmed it fixed the issue.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4168: Testsuite: transferdialattempts test

[Matt Jordan]

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

Ship it!


- Matt Jordan


On Nov. 17, 2014, 1:48 p.m., Mark Michelson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4168/
> ---
> 
> (Updated Nov. 17, 2014, 1:48 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This is a testsuite test that tests the transferdialattempts option in 
> features.conf. The test-config.yaml file explains things pretty well.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/bridge/tests.yaml 5885 
>   /asterisk/trunk/tests/bridge/atxfer_retries/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/bridge/atxfer_retries/configs/ast1/features.conf 
> PRE-CREATION 
>   /asterisk/trunk/tests/bridge/atxfer_retries/configs/ast1/extensions.conf 
> PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/4168/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4090: testsuite: add basic valgrind support

[Scott Griepentrog]

> On Nov. 18, 2014, 8:18 a.m., Corey Farrell wrote:
> > Please discard my findings, they are minor.  I'd like to see this committed 
> > ASAP so further improvements can be made against it.
> 
> Scott Griepentrog wrote:
> I like your idea of adding an option to pass valgrind options, but it 
> needs to first be set to write logs to the appropriate run_x/asty directory 
> so there isn't a conflict between multiple asterisk instances.  Then a simple 
> parser added to check the log for critical issues that trigger a test 
> failure, which then get included in the test results, even if in an 
> abbreviated form.  Not sure how best to pass leak info other than just 
> leaving it in the log though.
> 
> Corey Farrell wrote:
> Upon further thought, I'm not sure it's desirable to be able to add 
> options through the command-line.  "Extra options read from ~/.valgrindrc, 
> $VALGRIND_OPTS, ./.valgrindrc".  So I think in most cases it would be best 
> for people to create ./.valgrindrc.  Maybe we can add that to svn:ignore for 
> '.'.  But as you said, getting the logs to run_x/asty dirs is more important. 
>  Once this change is submitted I will look at putting the logs in the 
> appropriate dir.
> 
> As for parsing the test results, I think this would require using 
> --xml-file=, then using libxml and/or libxslt (through python, sorry I don't 
> know the modules for this).  Anything we do to parse the text-based valgrind 
> output will be a fragile hack.

Agreed (fragile hacks to be avoided).  There is code for parsing the xml file 
log (among other things) in https://reviewboard.asterisk.org/r/3496/, although 
parts of it are a bit convoluted (it attempts to reduce the stack traces of 
multiple issues down to a single tree for easier human consumption).


- Scott


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


On Nov. 18, 2014, 9:49 a.m., Scott Griepentrog wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4090/
> ---
> 
> (Updated Nov. 18, 2014, 9:49 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This adds very basic valgrind support, which is convenient for manual test 
> runs but does not (yet) include support for more automated valgrind usage. 
> 
> 1) CLI flag '-V' enables valgrind (./runtests -V -t tests/test)
> 
> 2) Minimal changes to testsuite, other improvements can be added later if 
> desired
> 
> 3) Valgrind output is picked up by error logging and shown after test run.
> 
> 4) Unlike previous valgrind attempt, this one works fine on tests with 
> multiple asterisk instances
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/runtests.py 5733 
>   /asterisk/trunk/lib/python/asterisk/test_case.py 5733 
>   /asterisk/trunk/lib/python/asterisk/asterisk.py 5733 
> 
> Diff: https://reviewboard.asterisk.org/r/4090/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

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

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

Re: [asterisk-dev] [Code Review] 3496: testsuite: add valgrind support

[Scott Griepentrog]

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

(Updated Nov. 18, 2014, 9:53 a.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers.


Repository: testsuite


Description
---

This patch adds support for running Asterisk under Valgrind (said 
"Val-Grinned") to check for memory allocation and reference problems.

To use, add -V to ./runtests.py and get a cup of coffee.  Any errors will be 
displayed in a stack trace format.

Tests can also activate valgrind in the yaml configuration.

By default, only confirmed leaks will be shown - thoses where all copies of the 
pointer to the allocation have been released.  Additional leak checking can be 
enabled.


Diffs
-

  /asterisk/trunk/runtests.py 5100 
  /asterisk/trunk/lib/python/asterisk/valgrind.py PRE-CREATION 
  /asterisk/trunk/lib/python/asterisk/test_config.py 5100 
  /asterisk/trunk/lib/python/asterisk/test_case.py 5100 
  /asterisk/trunk/lib/python/asterisk/asterisk.py 5100 
  /asterisk/trunk/configs/valgrind.supp PRE-CREATION 

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


Testing
---

Used to locate reference problems on Userevent issue, and incorporated several 
improvements over the prior attempt.


Thanks,

Scott Griepentrog

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

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

Re: [asterisk-dev] [Code Review] 4090: testsuite: add basic valgrind support

[Corey Farrell]

> On Nov. 18, 2014, 9:18 a.m., Corey Farrell wrote:
> > Please discard my findings, they are minor.  I'd like to see this committed 
> > ASAP so further improvements can be made against it.
> 
> Scott Griepentrog wrote:
> I like your idea of adding an option to pass valgrind options, but it 
> needs to first be set to write logs to the appropriate run_x/asty directory 
> so there isn't a conflict between multiple asterisk instances.  Then a simple 
> parser added to check the log for critical issues that trigger a test 
> failure, which then get included in the test results, even if in an 
> abbreviated form.  Not sure how best to pass leak info other than just 
> leaving it in the log though.

Upon further thought, I'm not sure it's desirable to be able to add options 
through the command-line.  "Extra options read from ~/.valgrindrc, 
$VALGRIND_OPTS, ./.valgrindrc".  So I think in most cases it would be best for 
people to create ./.valgrindrc.  Maybe we can add that to svn:ignore for '.'.  
But as you said, getting the logs to run_x/asty dirs is more important.  Once 
this change is submitted I will look at putting the logs in the appropriate dir.

As for parsing the test results, I think this would require using --xml-file=, 
then using libxml and/or libxslt (through python, sorry I don't know the 
modules for this).  Anything we do to parse the text-based valgrind output will 
be a fragile hack.


- Corey


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


On Nov. 18, 2014, 10:49 a.m., Scott Griepentrog wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4090/
> ---
> 
> (Updated Nov. 18, 2014, 10:49 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This adds very basic valgrind support, which is convenient for manual test 
> runs but does not (yet) include support for more automated valgrind usage. 
> 
> 1) CLI flag '-V' enables valgrind (./runtests -V -t tests/test)
> 
> 2) Minimal changes to testsuite, other improvements can be added later if 
> desired
> 
> 3) Valgrind output is picked up by error logging and shown after test run.
> 
> 4) Unlike previous valgrind attempt, this one works fine on tests with 
> multiple asterisk instances
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/runtests.py 5733 
>   /asterisk/trunk/lib/python/asterisk/test_case.py 5733 
>   /asterisk/trunk/lib/python/asterisk/asterisk.py 5733 
> 
> Diff: https://reviewboard.asterisk.org/r/4090/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4090: testsuite: add basic valgrind support

[Scott Griepentrog]

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

(Updated Nov. 18, 2014, 9:49 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 5942


Repository: testsuite


Description
---

This adds very basic valgrind support, which is convenient for manual test runs 
but does not (yet) include support for more automated valgrind usage. 

1) CLI flag '-V' enables valgrind (./runtests -V -t tests/test)

2) Minimal changes to testsuite, other improvements can be added later if 
desired

3) Valgrind output is picked up by error logging and shown after test run.

4) Unlike previous valgrind attempt, this one works fine on tests with multiple 
asterisk instances


Diffs
-

  /asterisk/trunk/runtests.py 5733 
  /asterisk/trunk/lib/python/asterisk/test_case.py 5733 
  /asterisk/trunk/lib/python/asterisk/asterisk.py 5733 

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


Testing
---


Thanks,

Scott Griepentrog

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

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

Re: [asterisk-dev] [Code Review] 4090: testsuite: add basic valgrind support

[Scott Griepentrog]

> On Oct. 16, 2014, 5:58 p.m., Kevin Harwell wrote:
> > /asterisk/trunk/runtests.py, lines 461-462
> > 
> >
> > Not a huge fan of using an environment variable for this (could 
> > probably be convinced otherwise though).  Maybe pass in as a param?

While I concur with your distaste for using an environment variable like this, 
it has several advantages:

1) transparently gets passed to lib/python/asterisk/asterisk.py even if a 
custom run-test python application is being used (doesn't require rewriting 
existing tests)

2) tests written in other langauges can test for the flag (although I don't see 
a need for this happening)

3) It is possible to set the environment variable before calling ./runtests.py 
to trigger valgrind usage (although this will be more useful later when 
automated failure detection is added).


- Scott


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


On Oct. 16, 2014, 4:23 p.m., Scott Griepentrog wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4090/
> ---
> 
> (Updated Oct. 16, 2014, 4:23 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This adds very basic valgrind support, which is convenient for manual test 
> runs but does not (yet) include support for more automated valgrind usage. 
> 
> 1) CLI flag '-V' enables valgrind (./runtests -V -t tests/test)
> 
> 2) Minimal changes to testsuite, other improvements can be added later if 
> desired
> 
> 3) Valgrind output is picked up by error logging and shown after test run.
> 
> 4) Unlike previous valgrind attempt, this one works fine on tests with 
> multiple asterisk instances
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/runtests.py 5733 
>   /asterisk/trunk/lib/python/asterisk/test_case.py 5733 
>   /asterisk/trunk/lib/python/asterisk/asterisk.py 5733 
> 
> Diff: https://reviewboard.asterisk.org/r/4090/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4090: testsuite: add basic valgrind support

[Scott Griepentrog]

> On Nov. 18, 2014, 8:18 a.m., Corey Farrell wrote:
> > Please discard my findings, they are minor.  I'd like to see this committed 
> > ASAP so further improvements can be made against it.

I like your idea of adding an option to pass valgrind options, but it needs to 
first be set to write logs to the appropriate run_x/asty directory so there 
isn't a conflict between multiple asterisk instances.  Then a simple parser 
added to check the log for critical issues that trigger a test failure, which 
then get included in the test results, even if in an abbreviated form.  Not 
sure how best to pass leak info other than just leaving it in the log though.


- Scott


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


On Oct. 16, 2014, 4:23 p.m., Scott Griepentrog wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4090/
> ---
> 
> (Updated Oct. 16, 2014, 4:23 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This adds very basic valgrind support, which is convenient for manual test 
> runs but does not (yet) include support for more automated valgrind usage. 
> 
> 1) CLI flag '-V' enables valgrind (./runtests -V -t tests/test)
> 
> 2) Minimal changes to testsuite, other improvements can be added later if 
> desired
> 
> 3) Valgrind output is picked up by error logging and shown after test run.
> 
> 4) Unlike previous valgrind attempt, this one works fine on tests with 
> multiple asterisk instances
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/runtests.py 5733 
>   /asterisk/trunk/lib/python/asterisk/test_case.py 5733 
>   /asterisk/trunk/lib/python/asterisk/asterisk.py 5733 
> 
> Diff: https://reviewboard.asterisk.org/r/4090/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4186: stringfields: Fix regression from fix for unintentional memory retention and another issue exposed by the fix

[Corey Farrell]

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

(Updated Nov. 18, 2014, 9:25 a.m.)


Review request for Asterisk Developers and rmudgett.


Changes
---

Add JIRA ticket.


Bugs: ASTERISK-24535
https://issues.asterisk.org/jira/browse/ASTERISK-24535


Repository: Asterisk


Description
---

This addresses a regression in the previous fix that applies to all versions.  
When __ast_string_field_ptr_grow is called by 
ast_string_field_ptr_set_by_fields, it needs to be passed &target, not __p__.  
In the current code if __ast_string_field_ptr_grow actually does anything, it 
will cause *__p__ != target.  Unfortunately in this case *__p__ points to the 
new address, target to the old.  This may cause too much data to be written to 
the old space for the string, and this could cause memory corruption.  This was 
the first thing I noticed when attempting to troubleshoot 
res/parking/dynamic_parking_variables unit test failure, but did not fix the 
test.

Also needed to get the unit test working again is a fix for 
ast_string_fields_copy in 12+.  The existing code relies on the fact that 
__ast_string_field_release_active never previously zeroed pool->used, so 
keeping the existing pointer was ok.  Setting each field to 
__ast_string_field_empty after releasing the memory seems to resolve the issue.


Diffs
-

  /branches/12/include/asterisk/stringfields.h 427735 

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


Testing
---

Full testsuite against 12.  I had 17 failures, but that is normal on my system. 
 I re-ran the 17 tests without this patch, they still failed.


Thanks,

Corey Farrell

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

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

Re: [asterisk-dev] [Code Review] 4090: testsuite: add basic valgrind support

[Corey Farrell]

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

Ship it!


Please discard my findings, they are minor.  I'd like to see this committed 
ASAP so further improvements can be made against it.

- Corey Farrell


On Oct. 16, 2014, 5:23 p.m., Scott Griepentrog wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4090/
> ---
> 
> (Updated Oct. 16, 2014, 5:23 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This adds very basic valgrind support, which is convenient for manual test 
> runs but does not (yet) include support for more automated valgrind usage. 
> 
> 1) CLI flag '-V' enables valgrind (./runtests -V -t tests/test)
> 
> 2) Minimal changes to testsuite, other improvements can be added later if 
> desired
> 
> 3) Valgrind output is picked up by error logging and shown after test run.
> 
> 4) Unlike previous valgrind attempt, this one works fine on tests with 
> multiple asterisk instances
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/runtests.py 5733 
>   /asterisk/trunk/lib/python/asterisk/test_case.py 5733 
>   /asterisk/trunk/lib/python/asterisk/asterisk.py 5733 
> 
> Diff: https://reviewboard.asterisk.org/r/4090/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4188: segfault when playing back voicemail under high concurrency with an IMAP backend

[Matt Jordan]

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


>From http://www.washington.edu/imap/documentation/internal.txt.html:

{quote}
* * * IMPORTANT * * *

 Any multi-threaded application should test stream->lock prior to
calling any c-client stream functions.  Any attempt to call a
mail_xxx() function while one is already in progress on the same
stream will cause the application to fail in unpredictable ways.

 Note that this check is insufficient in a preemptive-scheduling
multi-tasking application due to the possibility of a timing race.
Such applications must be written so that only one process accesses
the stream, or to have a higher level lock.

 Since MAIL operations will not finish until they are completed, a
single-tasking application does not have to worry about this problem,
except in the callback invoked from MAIL (e.g. mm_exists(), etc.) in which
case the stream is *always* locked.
{quote}

So, a few things from this:
(1) Based on the description from the UW IMAP documentation, locking vms->lock 
is sufficient *if* other mail accesses also lock the same vms object for that 
stream. If that isn't happening, then your patch probably won't fix anything, 
since both mail_open calls were already protected by the vms->lock and your 
global lock doesn't protect any other mail_ accesses. The only way your 
patch would affect anything is if there were two different vms objects being 
used to open the same stream at the same time.
(2) Your backtrace on the issue doesn't show concurrent accesses to vm_execmain 
- although a lot of symbols are missing - so right now it's impossible to tell 
who the offending accesses are. It's also impossible to know if it is due to 
two concurrent accesses of mail_open with different vms objects, or something 
else.

Generally, I'm not this patch fixes your issue.

- Matt Jordan


On Nov. 17, 2014, 9:03 a.m., David Duncan Ross Palmer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4188/
> ---
> 
> (Updated Nov. 17, 2014, 9:03 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24516
> https://issues.asterisk.org/jira/browse/ASTERISK-24516
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Asterisk segfaults when playing back voicemail under high concurrency with an 
> IMAP backend
> 
> 
> Diffs
> -
> 
>   /trunk/apps/app_voicemail.c 427675 
> 
> Diff: https://reviewboard.asterisk.org/r/4188/diff/
> 
> 
> Testing
> ---
> 
> Rapid load testing performed with {{SIPp}}:
> {code}
> sipp -sn uac -d 7000 -s ‘*1’ 127.0.0.1 -l 400 -mp 5606
> {code}
> 
> 
> Thanks,
> 
> David Duncan Ross Palmer
> 
>

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

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