[asterisk-dev] [Code Review] 4061: testsuite: Initial test for res_phoneprov

2014-10-08 Thread George Joseph 

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

Review request for Asterisk Developers.


Repository: testsuite


Description
---

This is the first test for res_phoneprov.


Diffs
-

  asterisk/trunk/tests/tests.yaml 5690 
  asterisk/trunk/tests/phoneprov/tests.yaml PRE-CREATION 
  asterisk/trunk/tests/phoneprov/res_phoneprov/test-config.yaml PRE-CREATION 
  asterisk/trunk/tests/phoneprov/res_phoneprov/run-test PRE-CREATION 
  asterisk/trunk/tests/phoneprov/res_phoneprov/configs/ast1/users.conf 
PRE-CREATION 
  asterisk/trunk/tests/phoneprov/res_phoneprov/configs/ast1/phoneprov.conf 
PRE-CREATION 
  asterisk/trunk/tests/phoneprov/res_phoneprov/cfgex.txt PRE-CREATION 
  asterisk/trunk/tests/phoneprov/res_phoneprov/cfgbase.txt PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/4061/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] 4054: Stasis: Reduce processing for declined message types

2014-10-08 Thread opticron 

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

(Updated Oct. 8, 2014, 1:11 p.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

This change reduces the processing required (an AO2 lookup) for determining 
when an error message should be emitted if a Stasis message type is missing.


Diffs
-

  branches/13/main/stasis.c 424769 
  branches/13/include/asterisk/stasis.h 424425 

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


Testing
---

Verified that the media indexer could be disabled without error messages 
showing up incorrectly.


Thanks,

opticron

-- 
_
-- 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] Asterisk ARI improper usage pattern for channels REST API

2014-10-08 Thread Scott Griepentrog 
The only two ARI methods I'm seeing where a priority is used are:

1) Channel origination (optionally sending channel to dialplan instead of
into a Stasis app)

2) Channel continue (jump out of application into a specific point in
dialplan)

And yes, you are correct in pointing out that the continue is using an int
rather than a long, which is clearly a consistency mistake in the API.

In both cases, the priority is given as a part of typical
context/extension/priority method of addressing where exactly in the
dialplan you want to send the channel to.  The most common scenario is to
have a priority 1 as the starting point.  The other numbers (using same =>
n) are then sequential but arbitrary, and it is generally not necessary to
know what they actually are to jump to them directly.

As you point out, labels in dialplan are a convenient way of allowing
dialplan execution to jump or goto a specific point without needing to know
the actual priority number.  Unfortunately, the implementation in ARI does
not (currently) allow for a label to be specified.  This is a limitation
that should probably be fixed - possibly a topic of discussion for
Astridevcon.

For a workaround, I would suggest using arbitrarily large priorities to
jump to the correct label where this functionality is needed.

For example:

exten => _x.,1,Answer()
   same => n,GoToIf($["${GOTTAGONOW}" = "1"]?louie)
   same => n,Playback(tt-monkeys)
   same => n,Hangup()
   same => n(louie),Playback(lyrics-louie-louie)
   same => n,Hangup()

exten => _x.,10001,GoTo(louie)

On Wed, Oct 8, 2014 at 8:33 AM, Nir Simionovich 
wrote:

> Hi Guys,
>
>   While working on PHPARI, I've come to a realization that the channels
> REST API
> has a slight issue - primarily, its usage of the "priority" member in the
> REST API.
>
>   Currently, the specification states that "priority" is either "int" or
> "long" (depending
> on the request).
>
>   The problem with that is for someone like myself, who codes dialplan in
> AEL or
> using the "same => n," or the "exten => _X.,n," methodology - we have no
> visibility
> of priority numbers - we use labels.
>
>   I'm not that familiar with the ARI part of the Asterisk code yet, as I'm
> focused on how
> to actually work with it, but this is somewhat of a show stopper in my
> book, as all my
> existing code relies heavily on label usage.
>
>   Btw, I tried pushing a label into the REST interface, got a 500 error -
> which means
> it's designed to work with numbers and not labels.
>
> Regards,
>   Nir S
>
>
>
> --
> _
> -- 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
>



-- 
[image: Digium logo]
Scott Griepentrog
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090
Check us out at: http://digium.com · http://asterisk.org
-- 
_
-- 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] 4039: res_rtp_asterisk: Crash if no candidates received for component

2014-10-08 Thread Joshua Colp 


> On Oct. 7, 2014, 6:45 p.m., Joshua Colp wrote:
> > I don't think this goes far enough. What if I receive no candidates for 
> > RTCP? It would still crash.
> 
> Kevin Harwell wrote:
> I tested for this.  The only time it crashes is when there are no RTP 
> candidates in the list.  If there are no RTCP candidates in the list it does 
> not crash.

I still think we should do it as that's relying on undocumented behavior. In 
fact the documentation says the opposite - that there must be at least one 
candidate per component. If that becomes true we are hosed.


- Joshua


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


On Oct. 1, 2014, 3:43 p.m., Kevin Harwell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4039/
> ---
> 
> (Updated Oct. 1, 2014, 3:43 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24383
> https://issues.asterisk.org/jira/browse/ASTERISK-24383
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When starting ice if there is not at least one remote ice candidate with an 
> RTP component asterisk will crash. This is due to an assertion in pjnath as 
> it expects at least one candidate with an RTP component. Added a check to 
> make sure at least one candidate contains an RTP component.
> 
> 
> Diffs
> -
> 
>   branches/12/res/res_rtp_asterisk.c 424285 
> 
> Diff: https://reviewboard.asterisk.org/r/4039/diff/
> 
> 
> Testing
> ---
> 
> Sent asterisk a list of ice candidates containing only RTCP components (no 
> RTP ones) and observed the crash.  After applying the patch ran the scenario 
> again and it did not crash.
> 
> 
> 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

[asterisk-dev] [Code Review] 4057: bridge: Every time a bridge lies during the smart bridge operation I cry

2014-10-08 Thread Joshua Colp 

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

Right now when a smart bridge operation occurs the bridge provided to the old 
technology is full of lies. This has the result of making technology 
implementations more complex because they can't assume the bridge is truthful, 
resulting in them storing more state than is needed or having additional code 
paths.

The attached change makes the bridge provided to the old technology truthful. 
The bridge will contain all the channels that are actually in the old bridge 
instead of none. As a result the bridge_native_rtp module can be made a bit 
dumber and slimmed down. This makes the smart bridge operation, to the old 
technology, a series of normal leave calls.


Diffs
-

  /branches/12/main/bridge.c 424413 
  /branches/12/bridges/bridge_native_rtp.c 424413 

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


Testing
---

Performed calls and ran tests.


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] 4053: res_pjsip_history: A debugging module for busy systems

2014-10-08 Thread Matt Jordan 


> On Oct. 8, 2014, 9:53 a.m., Scott Griepentrog wrote:
> > If we were to follow the CLI convention, it would be:
> > 
> > pjsip show histories 4 9 
> > 
> > and 
> > 
> > pjsip show history 4
> > 
> > It might be helpful to also add an alias for 'pjsip show historys'

Er... I'm not sure I like the plural form. There's really only one history for 
the PJSIP stack.


- Matt


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


On Oct. 8, 2014, 8:55 a.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4053/
> ---
> 
> (Updated Oct. 8, 2014, 8:55 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> While debugging things at SIPit, I found that the capabilities afforded by 
> res_pjsip_logger to be inadequate for tracing SIP messages on the CLI. Often, 
> so many requests/responses were received -- often with very large SDPs -- in 
> a short period of time that after a single call scenario, the initial 
> requests/responses had already been expunged from the CLI buffer. 
> Furthermore, displaying every single SIP request/response was often 
> counterproductive - OPTIONS, SUBSCRIBE, and even REGISTER requests were often 
> interleaved in the call scenarios, making it difficult to find or trace 
> portions of a call.
> 
> This isn't the fault of res_pjsip_logger: it was doing exactly what it was 
> designed to do. And res_pjsip_logger is absolutely necessary for getting full 
> logs when a problem occurs. However, it isn't designed for debugging things 
> on the CLI. Hence, this module.
> 
> res_pjsip_history records every request/response received/transmitted through 
> the PJSIP stack, but does not bother dumping them to the CLI. Instead, it 
> provides a few CLI comamnds to access the recorded messages:
> 
> * pjsip set history {on|off} - enable/disable the history
> * pjsip show history [min [max]] - display the entire history, or segments of 
> the history.
> * pjsip show entry {num} - display a particular history entry
> 
> Because we store all received/transmitted requests/responses, the module is 
> only suitable for debugging purposes. Leaving it permanently odd is a bad 
> idea, for obvious reasons. When the history is turned off, all messages are 
> purged and the history reset.
> 
> As an example, we can record some history and display all of the messages:
> 
> *CLI> pjsip show history
> No.  Timestamp  Rx/Tx AddressCall-ID  SIP Message
>  ==   
>  1412775534.791 RX: 127.0.0.1:22428  d56324c8f042034aae29 OPTIONS 
> sip:127.0.0.1 SIP/2.0
> 0001 1412775534.792 TX: 127.0.0.1:22428  d56324c8f042034aae29 SIP/2.0 200 OK
> 0002 1412775540.277 RX: 127.0.0.1:22428  86cd74e458e76b79e267 OPTIONS 
> sip:127.0.0.1 SIP/2.0
> 0003 1412775540.277 TX: 127.0.0.1:22428  86cd74e458e76b79e267 SIP/2.0 200 OK
> 0004 1412775541.763 RX: 127.0.0.1:22428  f4c0050f5b604fc52ecc INVITE 
> sip:200@127.0.0.1 SIP/2.0
> 0005 1412775541.765 TX: 127.0.0.1:22428  f4c0050f5b604fc52ecc SIP/2.0 200 OK
> 0006 1412775541.766 TX: 127.0.0.1:22428  f4c0050f5b604fc52ecc SIP/2.0 200 OK
> 0007 1412775541.780 RX: 127.0.0.1:22428  f4c0050f5b604fc52ecc ACK 
> sip:127.0.0.1:5060 SIP/2.0
> 0008 1412775543.767 RX: 127.0.0.1:22428  f4c0050f5b604fc52ecc BYE 
> sip:127.0.0.1:5060 SIP/2.0
> 0009 1412775543.768 TX: 127.0.0.1:22428  f4c0050f5b604fc52ecc SIP/2.0 200 OK
> 0010 1412775547.823 RX: 127.0.0.1:22428  ab6fc9f37aa1dc5ed038 SUBSCRIBE 
> sip:1000@127.0.0.1 SIP/2.0
> 0011 1412775547.824 TX: 127.0.0.1:22428  ab6fc9f37aa1dc5ed038 SIP/2.0 481 
> Call/Transaction Does Not Exist
> 0012 1412775547.826 RX: 127.0.0.1:22428  ba4ed4625cbb3282b34c REGISTER 
> sip:127.0.0.1 SIP/2.0
> 0013 1412775547.841 TX: 127.0.0.1:22428  ba4ed4625cbb3282b34c SIP/2.0 200 OK
> 0014 1412775549.854 RX: 127.0.0.1:34899  ca022bf6e5a31b306bfd REGISTER 
> sip:127.0.0.1 SIP/2.0
> 0015 1412775549.870 TX: 127.0.0.1:34899  ca022bf6e5a31b306bfd SIP/2.0 200 OK
> 0016 1412775549.876 RX: 127.0.0.1:34899  d92c91d540a36d2cbca1 SUBSCRIBE 
> sip:1000@127.0.0.1 SIP/2.0
> 0017 1412775549.876 TX: 127.0.0.1:34899  d92c91d540a36d2cbca1 SIP/2.0 200 OK
> 0018 1412775549.877 TX: 127.0.0.1:34899  d92c91d540a36d2cbca1 NOTIFY 
> sip:1000@127.0.0.1:34899;transport=udp;registering_acc=127_0_0_1 SIP/2.0
> 0019 1412775549.877 RX: 127.0.0.1:34899  32cca4f61cbba6cbe47f OPTIONS 
> sip:127.0.0.1 SIP/2.0
> 0020 1412775549.877 TX: 127.0.0.1:34899  32cca4f61cbba6cbe47f SIP/2.0 200 OK
> 0021 1412775549.889 RX: 127.0.0.1:34899  d92c91d540a36d2cbca1 SIP/2.0 200 OK
> 0022 141277.376 RX: 127.0.0

Re: [asterisk-dev] [Code Review] 4051: testsuite: chan_sip: Test dialog leak reported in ASTERISK-20784.

2014-10-08 Thread wdoekes 

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

(Updated Oct. 8, 2014, 4:13 p.m.)


Review request for Asterisk Developers.


Changes
---

Fix Contact parsing.
Fix red blob.


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


Repository: testsuite


Description
---

Old bug from end of 2012: under the right circumstances, a leg never gets
destroyed, resulting in file leaks and other nastiness.

This tests that scenario and the fix as presented in patch_asterisk_20784.txt.


Diffs (updated)
-

  /asterisk/trunk/tests/channels/SIP/tests.yaml 5684 
  /asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/test-config.yaml 
PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/sipp/bob.xml 
PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/sipp/alice.xml 
PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/run-test 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/configs/ast1/sip.conf 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/configs/ast1/extensions.conf
 PRE-CREATION 

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


Testing
---

Before applying patch_asterisk_20784.txt:




  
Running ['tests/channels/SIP/no_ack_dialog_cleanup/run-test'] ...
[Oct 08 12:26:54] WARNING[10545]: __main__:104 ret: Expected 0 sip dialog 
objects:
  name: 42da441f7021d3ff2b1c194b124395f8@127.0.0.1:5060
  type: dialog
  objflags: 0
  refcount: 1

  



After applying:




  



Thanks,

wdoekes

-- 
_
-- 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] 4056: chan_sip: Fix so asterisk won't send reINVITE after a BYE.

2014-10-08 Thread wdoekes 

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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

The bug report reports:

> i am receiving faxes with receiveFAX().
> after transmitting the document with t38 asterisk changes
> back to g711.
> Sometimes it happens that even after receiving a BYE asterisk
> is sending these Re-INVITEs.

I've noticed that too. I created a testcase that reliably reproduces
it here: https://reviewboard.asterisk.org/r/4055/


Diffs
-

  /branches/1.8/channels/chan_sip.c 424667 

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


Testing
---

Yes. But only that test case. I'm running a -g SIP test now.


Thanks,

wdoekes

-- 
_
-- 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] 4055: testsuite: chan_sip: Test unscheduling reINVITE after call hangup.

2014-10-08 Thread wdoekes 

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

Review request for Asterisk Developers.


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


Repository: testsuite


Description
---

ASTERISK-22791 details how asterisk resends a reINVITE even though the
call has already been hung up by a BYE.

This tests that problem.

Also note how the From/To are also reversed, since this is a reINVITE
*to* alice where alice is in the From.


Diffs
-

  /asterisk/trunk/tests/channels/SIP/tests.yaml 5684 
  /asterisk/trunk/tests/channels/SIP/no_reinvite_after_491/test-config.yaml 
PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/no_reinvite_after_491/sipp/bob.xml 
PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/no_reinvite_after_491/sipp/alice.xml 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/no_reinvite_after_491/configs/ast1/sip.conf 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/no_reinvite_after_491/configs/ast1/extensions.conf
 PRE-CREATION 

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


Testing
---

Before it is fixed:




  
Running ['./lib/python/asterisk/test_runner.py', 
'tests/channels/SIP/no_reinvite_after_491'] ...
[Oct 08 17:54:30] WARNING[4582]: sipp:437 processEnded: Resolving remote host 
'127.0.0.1'... Done.

[Oct 08 17:54:30] WARNING[4582]: sipp:437 processEnded: 2014-10-08  
17:54:30.202158 1412783670.202158: Aborting call on unexpected message for 
Call-Id '1-4636@127.0.0.1': while pausing (index 10), received 'INVITE 
sip:alice@127.0.0.1:5062 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK717504e3;rport
Max-Forwards: 70
From: alice ;tag=4636SIPpTag001
To: bob ;tag=as7d7023cd
Contact: 
Call-ID: 1-4636@127.0.0.1
CSeq: 103 INVITE
User-Agent: Asterisk PBX SVN-branch-1.8-r424181
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
PUBLISH, MESSAGE
Supported: replaces, timer
X-asterisk-Info: SIP re-invite (External RTP bridge)
Content-Type: application/sdp
Content-Length: 296

v=0
o=root 30542954 30542956 IN IP4 127.0.0.1
s=Asterisk PBX SVN-branch-1.8-r424181
c=IN IP4 127.0.0.1
t=0 0
m=image 4725 udptl t38
c=IN IP4 127.0.0.1
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxDatagram:389
a=T38FaxUdpEC:t38UDPRedundancy
'.

[Oct 08 17:54:30] WARNING[4582]: sipp:539 __scenario_callback: SIPp Scenario 
alice.xml Failed [1]
[Oct 08 17:54:30] WARNING[4582]: sipp:548 __evaluate_scenario_results: SIPp 
Scenario alice.xml Failed
[Oct 08 17:54:30] WARNING[4582]: sipp:402 kill: Killing SIPp Scenario bob.xml

  



After a possible fix:




  



Thanks,

wdoekes

-- 
_
-- 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] 4054: Stasis: Reduce processing for declined message types

2014-10-08 Thread opticron 

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

This change reduces the processing required (an AO2 lookup) for determining 
when an error message should be emitted if a Stasis message type is missing.


Diffs
-

  branches/13/main/stasis.c 424769 
  branches/13/include/asterisk/stasis.h 424425 

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


Testing
---

Verified that the media indexer could be disabled without error messages 
showing up incorrectly.


Thanks,

opticron

-- 
_
-- 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] 4053: res_pjsip_history: A debugging module for busy systems

2014-10-08 Thread Scott Griepentrog 

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


If we were to follow the CLI convention, it would be:

pjsip show histories 4 9 

and 

pjsip show history 4

It might be helpful to also add an alias for 'pjsip show historys'

- Scott Griepentrog


On Oct. 8, 2014, 8:55 a.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4053/
> ---
> 
> (Updated Oct. 8, 2014, 8:55 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> While debugging things at SIPit, I found that the capabilities afforded by 
> res_pjsip_logger to be inadequate for tracing SIP messages on the CLI. Often, 
> so many requests/responses were received -- often with very large SDPs -- in 
> a short period of time that after a single call scenario, the initial 
> requests/responses had already been expunged from the CLI buffer. 
> Furthermore, displaying every single SIP request/response was often 
> counterproductive - OPTIONS, SUBSCRIBE, and even REGISTER requests were often 
> interleaved in the call scenarios, making it difficult to find or trace 
> portions of a call.
> 
> This isn't the fault of res_pjsip_logger: it was doing exactly what it was 
> designed to do. And res_pjsip_logger is absolutely necessary for getting full 
> logs when a problem occurs. However, it isn't designed for debugging things 
> on the CLI. Hence, this module.
> 
> res_pjsip_history records every request/response received/transmitted through 
> the PJSIP stack, but does not bother dumping them to the CLI. Instead, it 
> provides a few CLI comamnds to access the recorded messages:
> 
> * pjsip set history {on|off} - enable/disable the history
> * pjsip show history [min [max]] - display the entire history, or segments of 
> the history.
> * pjsip show entry {num} - display a particular history entry
> 
> Because we store all received/transmitted requests/responses, the module is 
> only suitable for debugging purposes. Leaving it permanently odd is a bad 
> idea, for obvious reasons. When the history is turned off, all messages are 
> purged and the history reset.
> 
> As an example, we can record some history and display all of the messages:
> 
> *CLI> pjsip show history
> No.  Timestamp  Rx/Tx AddressCall-ID  SIP Message
>  ==   
>  1412775534.791 RX: 127.0.0.1:22428  d56324c8f042034aae29 OPTIONS 
> sip:127.0.0.1 SIP/2.0
> 0001 1412775534.792 TX: 127.0.0.1:22428  d56324c8f042034aae29 SIP/2.0 200 OK
> 0002 1412775540.277 RX: 127.0.0.1:22428  86cd74e458e76b79e267 OPTIONS 
> sip:127.0.0.1 SIP/2.0
> 0003 1412775540.277 TX: 127.0.0.1:22428  86cd74e458e76b79e267 SIP/2.0 200 OK
> 0004 1412775541.763 RX: 127.0.0.1:22428  f4c0050f5b604fc52ecc INVITE 
> sip:200@127.0.0.1 SIP/2.0
> 0005 1412775541.765 TX: 127.0.0.1:22428  f4c0050f5b604fc52ecc SIP/2.0 200 OK
> 0006 1412775541.766 TX: 127.0.0.1:22428  f4c0050f5b604fc52ecc SIP/2.0 200 OK
> 0007 1412775541.780 RX: 127.0.0.1:22428  f4c0050f5b604fc52ecc ACK 
> sip:127.0.0.1:5060 SIP/2.0
> 0008 1412775543.767 RX: 127.0.0.1:22428  f4c0050f5b604fc52ecc BYE 
> sip:127.0.0.1:5060 SIP/2.0
> 0009 1412775543.768 TX: 127.0.0.1:22428  f4c0050f5b604fc52ecc SIP/2.0 200 OK
> 0010 1412775547.823 RX: 127.0.0.1:22428  ab6fc9f37aa1dc5ed038 SUBSCRIBE 
> sip:1000@127.0.0.1 SIP/2.0
> 0011 1412775547.824 TX: 127.0.0.1:22428  ab6fc9f37aa1dc5ed038 SIP/2.0 481 
> Call/Transaction Does Not Exist
> 0012 1412775547.826 RX: 127.0.0.1:22428  ba4ed4625cbb3282b34c REGISTER 
> sip:127.0.0.1 SIP/2.0
> 0013 1412775547.841 TX: 127.0.0.1:22428  ba4ed4625cbb3282b34c SIP/2.0 200 OK
> 0014 1412775549.854 RX: 127.0.0.1:34899  ca022bf6e5a31b306bfd REGISTER 
> sip:127.0.0.1 SIP/2.0
> 0015 1412775549.870 TX: 127.0.0.1:34899  ca022bf6e5a31b306bfd SIP/2.0 200 OK
> 0016 1412775549.876 RX: 127.0.0.1:34899  d92c91d540a36d2cbca1 SUBSCRIBE 
> sip:1000@127.0.0.1 SIP/2.0
> 0017 1412775549.876 TX: 127.0.0.1:34899  d92c91d540a36d2cbca1 SIP/2.0 200 OK
> 0018 1412775549.877 TX: 127.0.0.1:34899  d92c91d540a36d2cbca1 NOTIFY 
> sip:1000@127.0.0.1:34899;transport=udp;registering_acc=127_0_0_1 SIP/2.0
> 0019 1412775549.877 RX: 127.0.0.1:34899  32cca4f61cbba6cbe47f OPTIONS 
> sip:127.0.0.1 SIP/2.0
> 0020 1412775549.877 TX: 127.0.0.1:34899  32cca4f61cbba6cbe47f SIP/2.0 200 OK
> 0021 1412775549.889 RX: 127.0.0.1:34899  d92c91d540a36d2cbca1 SIP/2.0 200 OK
> 0022 141277.376 RX: 127.0.0.1:34899  f65c7ea06475be757d2c INVITE 
> sip:1000@127.0.0.1 SIP/2.0
> 0023 141277.377 TX: 127.0.0.1:34899  f65c7ea06475be757d2c SIP/2.0 487 
> Request Terminated
> 0024 14127

[asterisk-dev] [Code Review] 4053: res_pjsip_history: A debugging module for busy systems

2014-10-08 Thread Matt Jordan 

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

While debugging things at SIPit, I found that the capabilities afforded by 
res_pjsip_logger to be inadequate for tracing SIP messages on the CLI. Often, 
so many requests/responses were received -- often with very large SDPs -- in a 
short period of time that after a single call scenario, the initial 
requests/responses had already been expunged from the CLI buffer. Furthermore, 
displaying every single SIP request/response was often counterproductive - 
OPTIONS, SUBSCRIBE, and even REGISTER requests were often interleaved in the 
call scenarios, making it difficult to find or trace portions of a call.

This isn't the fault of res_pjsip_logger: it was doing exactly what it was 
designed to do. And res_pjsip_logger is absolutely necessary for getting full 
logs when a problem occurs. However, it isn't designed for debugging things on 
the CLI. Hence, this module.

res_pjsip_history records every request/response received/transmitted through 
the PJSIP stack, but does not bother dumping them to the CLI. Instead, it 
provides a few CLI comamnds to access the recorded messages:

* pjsip set history {on|off} - enable/disable the history
* pjsip show history [min [max]] - display the entire history, or segments of 
the history.
* pjsip show entry {num} - display a particular history entry

Because we store all received/transmitted requests/responses, the module is 
only suitable for debugging purposes. Leaving it permanently odd is a bad idea, 
for obvious reasons. When the history is turned off, all messages are purged 
and the history reset.

As an example, we can record some history and display all of the messages:

*CLI> pjsip show history
No.  Timestamp  Rx/Tx AddressCall-ID  SIP Message
 ==   
 1412775534.791 RX: 127.0.0.1:22428  d56324c8f042034aae29 OPTIONS 
sip:127.0.0.1 SIP/2.0
0001 1412775534.792 TX: 127.0.0.1:22428  d56324c8f042034aae29 SIP/2.0 200 OK
0002 1412775540.277 RX: 127.0.0.1:22428  86cd74e458e76b79e267 OPTIONS 
sip:127.0.0.1 SIP/2.0
0003 1412775540.277 TX: 127.0.0.1:22428  86cd74e458e76b79e267 SIP/2.0 200 OK
0004 1412775541.763 RX: 127.0.0.1:22428  f4c0050f5b604fc52ecc INVITE 
sip:200@127.0.0.1 SIP/2.0
0005 1412775541.765 TX: 127.0.0.1:22428  f4c0050f5b604fc52ecc SIP/2.0 200 OK
0006 1412775541.766 TX: 127.0.0.1:22428  f4c0050f5b604fc52ecc SIP/2.0 200 OK
0007 1412775541.780 RX: 127.0.0.1:22428  f4c0050f5b604fc52ecc ACK 
sip:127.0.0.1:5060 SIP/2.0
0008 1412775543.767 RX: 127.0.0.1:22428  f4c0050f5b604fc52ecc BYE 
sip:127.0.0.1:5060 SIP/2.0
0009 1412775543.768 TX: 127.0.0.1:22428  f4c0050f5b604fc52ecc SIP/2.0 200 OK
0010 1412775547.823 RX: 127.0.0.1:22428  ab6fc9f37aa1dc5ed038 SUBSCRIBE 
sip:1000@127.0.0.1 SIP/2.0
0011 1412775547.824 TX: 127.0.0.1:22428  ab6fc9f37aa1dc5ed038 SIP/2.0 481 
Call/Transaction Does Not Exist
0012 1412775547.826 RX: 127.0.0.1:22428  ba4ed4625cbb3282b34c REGISTER 
sip:127.0.0.1 SIP/2.0
0013 1412775547.841 TX: 127.0.0.1:22428  ba4ed4625cbb3282b34c SIP/2.0 200 OK
0014 1412775549.854 RX: 127.0.0.1:34899  ca022bf6e5a31b306bfd REGISTER 
sip:127.0.0.1 SIP/2.0
0015 1412775549.870 TX: 127.0.0.1:34899  ca022bf6e5a31b306bfd SIP/2.0 200 OK
0016 1412775549.876 RX: 127.0.0.1:34899  d92c91d540a36d2cbca1 SUBSCRIBE 
sip:1000@127.0.0.1 SIP/2.0
0017 1412775549.876 TX: 127.0.0.1:34899  d92c91d540a36d2cbca1 SIP/2.0 200 OK
0018 1412775549.877 TX: 127.0.0.1:34899  d92c91d540a36d2cbca1 NOTIFY 
sip:1000@127.0.0.1:34899;transport=udp;registering_acc=127_0_0_1 SIP/2.0
0019 1412775549.877 RX: 127.0.0.1:34899  32cca4f61cbba6cbe47f OPTIONS 
sip:127.0.0.1 SIP/2.0
0020 1412775549.877 TX: 127.0.0.1:34899  32cca4f61cbba6cbe47f SIP/2.0 200 OK
0021 1412775549.889 RX: 127.0.0.1:34899  d92c91d540a36d2cbca1 SIP/2.0 200 OK
0022 141277.376 RX: 127.0.0.1:34899  f65c7ea06475be757d2c INVITE 
sip:1000@127.0.0.1 SIP/2.0
0023 141277.377 TX: 127.0.0.1:34899  f65c7ea06475be757d2c SIP/2.0 487 
Request Terminated
0024 141277.382 TX: 127.0.0.1:34899  6ddb9f94-9c20-4f83-8 INVITE 
sip:1000@127.0.0.1:34899;transport=udp;registering_acc=127_0_0_1 SIP/2.0
0025 141277.383 TX: 127.0.0.1:34899  f65c7ea06475be757d2c SIP/2.0 487 
Request Terminated
0026 1412775560.135 RX: 127.0.0.1:34899  f65c7ea06475be757d2c CANCEL 
sip:1000@127.0.0.1 SIP/2.0
0027 1412775560.135 TX: 127.0.0.1:34899  f65c7ea06475be757d2c SIP/2.0 200 OK
0028 1412775560.135 TX: 127.0.0.1:34899  f65c7ea06475be757d2c SIP/2.0 487 
Request Terminated
0029 1412775560.146 RX: 127.0.0.1:34899  f65c7ea06475be757d2c ACK 
sip:1000@127.0.0.1 SIP/2.0

Alternatively, we can display on a subset of the messages:

*CLI> pjsip show history 4 9
No.  Timestamp  Rx/

[asterisk-dev] Asterisk ARI improper usage pattern for channels REST API

2014-10-08 Thread Nir Simionovich 
Hi Guys,

  While working on PHPARI, I've come to a realization that the channels
REST API
has a slight issue - primarily, its usage of the "priority" member in the
REST API.

  Currently, the specification states that "priority" is either "int" or
"long" (depending
on the request).

  The problem with that is for someone like myself, who codes dialplan in
AEL or
using the "same => n," or the "exten => _X.,n," methodology - we have no
visibility
of priority numbers - we use labels.

  I'm not that familiar with the ARI part of the Asterisk code yet, as I'm
focused on how
to actually work with it, but this is somewhat of a show stopper in my
book, as all my
existing code relies heavily on label usage.

  Btw, I tried pushing a label into the REST interface, got a 500 error -
which means
it's designed to work with numbers and not labels.

Regards,
  Nir S
-- 
_
-- 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] 4052: chan_sip: Failure to receive ACK to SIP re-INVITE results in dialog leak.

2014-10-08 Thread wdoekes 

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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

A INVITE> asterisk INVITE> B
A <200 OK asterisk <200 OK B
A -ACK->  asterisk --ACK--> B
  asterisk  B
  (ack lost)
A -BYE--> asterisk
A <200 OK asterisk

At this point, the B leg leaks.

This patch is a re-indented version of patch_asterisk_20784.txt by
NITESH BANSAL.


Diffs
-

  /branches/1.8/channels/chan_sip.c 424667 

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


Testing
---

See: https://reviewboard.asterisk.org/r/4051/
Tested against Asterisk 1.8.


Thanks,

wdoekes

-- 
_
-- 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] 4051: testsuite: chan_sip: Test dialog leak reported in ASTERISK-20784.

2014-10-08 Thread wdoekes 

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

Review request for Asterisk Developers.


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


Repository: testsuite


Description
---

Old bug from end of 2012: under the right circumstances, a leg never gets
destroyed, resulting in file leaks and other nastiness.

This tests that scenario and the fix as presented in patch_asterisk_20784.txt.


Diffs
-

  /asterisk/trunk/tests/channels/SIP/tests.yaml 5684 
  /asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/test-config.yaml 
PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/sipp/bob.xml 
PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/sipp/alice.xml 
PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/run-test 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/configs/ast1/sip.conf 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/no_ack_dialog_cleanup/configs/ast1/extensions.conf
 PRE-CREATION 

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


Testing
---

Before applying patch_asterisk_20784.txt:




  
Running ['tests/channels/SIP/no_ack_dialog_cleanup/run-test'] ...
[Oct 08 12:26:54] WARNING[10545]: __main__:104 ret: Expected 0 sip dialog 
objects:
  name: 42da441f7021d3ff2b1c194b124395f8@127.0.0.1:5060
  type: dialog
  objflags: 0
  refcount: 1

  



After applying:




  



Thanks,

wdoekes

-- 
_
-- 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