Re: [asterisk-dev] [Code Review] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Pavel Troller]

> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/#review11635
> ---
> 
> 
> Hey wdoekes, I'm trying to figure out a similar chart for sendrpid=rpid
> 
>   | pres=allowed  
>| pres=prohibited  
>|
> --+--+-+
> trust_id_outbound=no  | Remote-Party-ID: "123" 
> ;party=calling;privacy=off;screen=no | 
> Remote-Party-ID: "123" 
> party=calling;privacy=full;screen=yes |
> --+--+-+
> trust_id_outbound=yes | Remote-Party-ID: "123" 
> ;party=calling;privacy=off;screen=no | 
> Remote-Party-ID: "123" 
> ;party=calling;privacy=full;screen=yes  |
> --+--+-+
> 
> Does that look about like what you would expect? This is keeping in mind that 
> the trust_id_outbound=no row mirrors the current expectations.
> 
> - Jonathan Rose
> 
Hi!
  PLEASE, don't touch the screening indicator (screen=xxx). It has NOTHING to 
do with presentation of the number. It should be setup by the dialplan to 
reflect, whether the number is verified by the exchange and it's valid (i.e. 
belongs to a person , who sent it) or not. When the number comes from the trunk 
(again, it's on the dialplan logic to recognize, that the connection is 
categorized as a trunk), it should be kept intact, i.e. the value coming from 
the trunk must be preserved for the outgoing connection. Forcing the screening 
indicator direclty from the chan_sip without any preceding knowledge is really 
a BAD_THING.
  With regards,
Pavel

-- 
_
-- 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] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[wdoekes]

> On April 16, 2014, 7:37 p.m., Jonathan Rose wrote:
> > Hey wdoekes, I'm trying to figure out a similar chart for sendrpid=rpid
> > 
> >   | pres=allowed
> >  | pres=prohibited  
> >|
> > --+--+-+
> > trust_id_outbound=no  | Remote-Party-ID: "123" 
> > ;party=calling;privacy=off;screen=no | 
> > Remote-Party-ID: "123" 
> > party=calling;privacy=full;screen=yes |
> > --+--+-+
> > trust_id_outbound=yes | Remote-Party-ID: "123" 
> > ;party=calling;privacy=off;screen=no | 
> > Remote-Party-ID: "123" 
> > ;party=calling;privacy=full;screen=yes  |
> > --+--+-+
> > 
> > Does that look about like what you would expect? This is keeping in mind 
> > that the trust_id_outbound=no row mirrors the current expectations.
> 
> jamuel wrote:
> For the sake of clarity would you guys mind adding a From column so that 
> we could see how the From header might or might not be mangled based on the 
> various use cases since that's where callerid is found typically?
> 
> Jonathan Rose wrote:
> The From: header should be completely unimpacted by these changes.

> Does that look about like what you would expect?
> This is keeping in mind that the trust_id_outbound=no row mirrors the current 
> expectations.

(You're missing a semi in that chart.)

Well. It depends on whether we're keeping things compatible or changing things 
for the better.

What I would expect, is for trust_id_outbound=no to clear out the RPID when 
pres=prohibited.


If I'm taking the ITSP view here, I have two concerns:

(A) I cannot send out privacy sensitive information to just anyone.
(B) Whenever possible, I want to be able to send CLI info to the device. Some 
take an RPID, others a PAI and others just the From.

If we use the suggested approach, I still cannot send RPID to 
trust_id_outbound=no devices.


I feel dirty saying it, but perhaps it is time for one of those nifty ternary 
booleans. Like: trust_id_outbound=legacy|no|yes. Where 'legacy' does the 
behaviour you suggest, 'no' clears out the headers in the top-right-chart, and 
'yes' keeps the headers in all cases. 


Lastly, a question, as I'm not sure on what the current behaviour is: if 
num-pres *or* name-pres is prohibited, then pres=prohibited in the above 
charts, right?
...
/* Select the wining[sic] presentation value. */
if (name_priority < number_priority) {
number_value = name_value;
}
...
Ok, that answers my question: yes.


- wdoekes


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


On April 16, 2014, 9:23 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 16, 2014, 9:23 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited for a peer that receives 
> P-Asserted-Identity, the P-Asserted-Identity shouldn't be anonymized, only 
> the normal From/Contact headers would be anonymized. This apparently 
> 
> The obvious method for dealing with this mid-release change is to make the 
> change into an option which de

Re: [asterisk-dev] [Code Review] 3434: libpri: Make TE-PTP mode respond to MDL TEI check requests.

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On April 15, 2014, 2:22 p.m., rmudgett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3434/
> ---
> 
> (Updated April 15, 2014, 2:22 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: PRI-165
> https://issues.asterisk.org/jira/browse/PRI-165
> 
> 
> Repository: LibPRI
> 
> 
> Description
> ---
> 
> Some BRI devices in France insist on checking TEI's when in point-to-point 
> mode.  If they don't get a response for TEI 0 they drop layer 1 even though 
> libpri keeps trying to bring layer 2 up.
> 
> * Made q921_mdl_receive() handle TEI check request messages in TE-PTP mode.  
> Had to change q921_mdl_send()/Q921_INIT() because the PTP modes do not setup 
> a link structure specifically for MDL as the PTMP modes do.
> 
> * Fixed q921_tei_check()/t201_expire() to check TEI's even if the network 
> side doesn't have any assigned.  This should make TE's that request the TEI 
> verify procedure (Q.921 Section 5.3.5) happy when the network side doesn't 
> have any TEI's allocated.
> 
> 
> Diffs
> -
> 
>   /branches/1.4/q921.c 2317 
> 
> Diff: https://reviewboard.asterisk.org/r/3434/diff/
> 
> 
> Testing
> ---
> 
> Setup a BRI connection where the network side is NT-PTMP mode and the CPE 
> side is TE-PTP mode.  Also made a temporary change to cause the NT-PTMP side 
> to initiate the TEI check request procedure on start up.
> Saw that the TE-PTP side responded with the permanently assigned TEI 0.
> Saw that the NT-PTMP side handled the unknown TEI by removing it. (TEI 0 is 
> unknown by that side.)
> 
> 
> 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] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Joshua Colp]

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



/branches/1.8/channels/chan_sip.c


If a legit fromdomain is specified you have to use it, or else you've just 
ignored the fromdomain configuration option.



/branches/1.8/channels/chan_sip.c


Previously if the presentation restriction was such that it wasn't 
allowed... then the anonymous header would get added. Reading this logic I 
don't see how the header would get added.


- Joshua Colp


On April 16, 2014, 9:23 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 16, 2014, 9:23 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited for a peer that receives 
> P-Asserted-Identity, the P-Asserted-Identity shouldn't be anonymized, only 
> the normal From/Contact headers would be anonymized. This apparently 
> 
> The obvious method for dealing with this mid-release change is to make the 
> change into an option which defaults off in 1.8-12 while defaulting on in 
> trunk. Also I'll need to add Upgrade notes for trunk since this might not 
> always be a desired behavior as well as CHANGES notes throughout to indicate 
> the new option if that's what we settle on.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/configs/sip.conf.sample 412438 
>   /branches/1.8/channels/sip/include/sip.h 412438 
>   /branches/1.8/channels/chan_sip.c 412438 
>   /branches/1.8/CHANGES 412438 
> 
> Diff: https://reviewboard.asterisk.org/r/3447/diff/
> 
> 
> Testing
> ---
> 
> Call from SIP peer A to SIP peer B
> settings for both peers:
> sendrpid = pai
> callerpres = prohib
> 
> 
> Invite sent from Asterisk to the recipient of the call
> --
> Prior to patch:
> 
> Audio is at 19640
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as13075548
> To: 
> Contact: 
> Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380
> Date: Tue, 11 Mar 2014 22:59:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Anonymous" 
> Content-Type: application/sdp
> Content-Length: 276
> 
> v=0
> o=root 473543868 473543868 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 19640 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> 
> 
> After patch:
> 
> Audio is at 11822
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK5d4a7db8;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as181a14e3
> To: 
> Contact: 
> Call-ID: 721bef28208f7633288e929c6e88824e@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380M
> Date: Tue, 11 Mar 2014 22:57:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Goldy Locks" 
> Privacy: id
> Content-Type: application/sdp
> Content-Length: 279
> 
> v=0
> o=root 1606369071 1606369071 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380M
> c=IN IP4 10.24.18.246
> t=0

Re: [asterisk-dev] [Code Review] 3444: Testsuite: PJSIP Callee Initiated Nominal Blind Transfers

[jbigelow]

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



./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/test-config.yaml


Should be "blind transfers Alice to Charlie".


- jbigelow


On April 14, 2014, 4:17 p.m., Scott Emidy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3444/
> ---
> 
> (Updated April 14, 2014, 4:17 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23447
> https://issues.asterisk.org/jira/browse/ASTERISK-23447
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> These three tests involve using PJSIP in order to execute callee initiated 
> blind transfers.
> 
> Also all three of these tests fail due to the unresolved issues 
> ASTERISK-23501 and ASTERISK-23502.
> 
> These tests required a few aspects in each test such as the SIPREFERTOHDR, 
> SIPREFERREDBYHDR, SIPTRANSFER, SIPREFERRINGCONTEXT, BLINDTRANSFER Event, 
> TRANSFER_CONTEXT that comes into play in the second iterations, and 
> Referred-By header. MusicOnHOldStart and MusicOnHoldStop were only required 
> for the callee_hold test.
> 
> The three tests were:
> 1) Callee initiated transfer with direct media (callee_direct_media) - This 
> consists of direct media being initiated between the endpoints before and 
> after the transfer.
> 2) Callee initiated transfer with hold (callee_hold) - This consists of a 
> blind transfer that puts the caller on hold before they are transferred.
> 3) Callee initiated transfer with REFER only (callee_only_refer) - This 
> consists of no hold or media just a basic REFER. Also John Bigelow made 
> changes to the pjsua_mod.py to be able to associate pjsua accounts with a 
> specific pjsua transport.
> 
> 
> Diffs
> -
> 
>   ./asterisk/trunk/tests/channels/pjsip/transfers/tests.yaml PRE-CREATION 
>   ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/tests.yaml 
> PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/transfer.py
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/test-config.yaml
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/test-config.yaml
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/sipp/charlie.xml
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/sipp/bob.xml
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/sipp/alice.xml
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/test-config.yaml
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/sipp/charlie.xml
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/sipp/bob.xml
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/sipp/alice.xml
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/configs/ast1/extensions.conf
>  PRE-CREATION 
>   ./asterisk/trunk/tests/channels/pjsip/tests.yaml 4957 
>   ./asterisk/trunk/lib/python/asterisk/pjsua_mod.py 4957 
> 
> Diff: https://reviewboard.asterisk.org/r/3444/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Scott Emidy
> 
>

-- 
_
-- 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] 3407: Test Suite: Nominal caller initiated blind transfer tests using PJSIP

[jbigelow]

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

(Updated April 16, 2014, 5:34 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 4964


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


Repository: testsuite


Description
---

These tests cover nominal caller initiated blind transfer tests using PJSIP.

Note: All three tests currently fail due to the issues described in 
ASTERISK-23501 & ASTERISK-23502.

Each test ensures the presents and values of the following:
* channel variables SIPREFERREDBYHDR, SIPREFERTOHDR, SIPTRANSFER, and 
SIPREFERRINGCONTEXT.
* the BlindTransfer event.
* the 'Referred-By' header in the INVITE sent to Charlie.

Each test also sets the TRANSFER_CONTEXT channel variable to ensure the 
transfer still occurs properly. The 'caller_with_hold' test additionally 
requires and checks the MusicOnHoldStart & MusicOnHoldStop events.

Tests:
* caller_refer_only: Uses PJSua library. Basic blind transfer without a hold or 
direct media being performed at any time. Changes were required to the 
pjsua_mod.py library to be able to associate pjsua accounts with a specific 
pjsua transport.
* caller_direct_media: Uses SIPp. Blind transfer with direct media between the 
endpoints before and after the transfer.
* caller_with_hold: Uses SIPp. Blind transfer with putting the callee on hold 
before the transfer.


Diffs
-

  /asterisk/trunk/tests/channels/pjsip/transfers/tests.yaml PRE-CREATION 
  /asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/tests.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_with_hold/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_with_hold/sipp/charlie.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_with_hold/sipp/bob.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_with_hold/sipp/alice.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_with_hold/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_with_hold/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_refer_only/transfer.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_refer_only/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_refer_only/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_refer_only/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_direct_media/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_direct_media/sipp/charlie.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_direct_media/sipp/bob.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_direct_media/sipp/alice.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_direct_media/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/caller_direct_media/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/channels/pjsip/tests.yaml 4911 
  /asterisk/trunk/lib/python/asterisk/pjsua_mod.py 4911 

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


Testing
---

* Added a pre-dial handler when dialing charlie to add the Referred-By
header and commented out the header match for the SIPREFERTOHDR channel
variable. This was to mimic a successful pass to validate the test. This was 
done for each.
** Executed tests in a loop 50+ times to ensure stability.
* Reviewed test suite & Asterisk logs.


Thanks,

jbigelow

-- 
_
-- 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] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Jonathan Rose]

> On April 16, 2014, 4:55 p.m., Joshua Colp wrote:
> > /branches/1.8/channels/chan_sip.c, line 11397
> > 
> >
> > Where do the anonymous values now get placed into the num/name/domain?
> 
> Jonathan Rose wrote:
> They come from the fromdomain... that thing that I called out above.

 S_OR(p->fromdomain, ast_sockaddr_stringify_host_remote(&p->ourip));

so from p->fromdomain


- Jonathan


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


On April 16, 2014, 4:23 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 16, 2014, 4:23 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited for a peer that receives 
> P-Asserted-Identity, the P-Asserted-Identity shouldn't be anonymized, only 
> the normal From/Contact headers would be anonymized. This apparently 
> 
> The obvious method for dealing with this mid-release change is to make the 
> change into an option which defaults off in 1.8-12 while defaulting on in 
> trunk. Also I'll need to add Upgrade notes for trunk since this might not 
> always be a desired behavior as well as CHANGES notes throughout to indicate 
> the new option if that's what we settle on.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/configs/sip.conf.sample 412438 
>   /branches/1.8/channels/sip/include/sip.h 412438 
>   /branches/1.8/channels/chan_sip.c 412438 
>   /branches/1.8/CHANGES 412438 
> 
> Diff: https://reviewboard.asterisk.org/r/3447/diff/
> 
> 
> Testing
> ---
> 
> Call from SIP peer A to SIP peer B
> settings for both peers:
> sendrpid = pai
> callerpres = prohib
> 
> 
> Invite sent from Asterisk to the recipient of the call
> --
> Prior to patch:
> 
> Audio is at 19640
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as13075548
> To: 
> Contact: 
> Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380
> Date: Tue, 11 Mar 2014 22:59:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Anonymous" 
> Content-Type: application/sdp
> Content-Length: 276
> 
> v=0
> o=root 473543868 473543868 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 19640 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> 
> 
> After patch:
> 
> Audio is at 11822
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK5d4a7db8;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as181a14e3
> To: 
> Contact: 
> Call-ID: 721bef28208f7633288e929c6e88824e@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380M
> Date: Tue, 11 Mar 2014 22:57:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Goldy Locks" 
> Privacy: id
> Content-Type: application/sdp
> Content-Length: 279
> 
> v=0
> o=root 1606369071 1606369071 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380M
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 11822 RTP/AVP 0 101
> a=rtpm

Re: [asterisk-dev] [Code Review] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Jonathan Rose]

> On April 16, 2014, 4:55 p.m., Joshua Colp wrote:
> > /branches/1.8/channels/chan_sip.c, line 11397
> > 
> >
> > Where do the anonymous values now get placed into the num/name/domain?

They come from the fromdomain... that thing that I called out above.


- Jonathan


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


On April 16, 2014, 4:23 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 16, 2014, 4:23 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited for a peer that receives 
> P-Asserted-Identity, the P-Asserted-Identity shouldn't be anonymized, only 
> the normal From/Contact headers would be anonymized. This apparently 
> 
> The obvious method for dealing with this mid-release change is to make the 
> change into an option which defaults off in 1.8-12 while defaulting on in 
> trunk. Also I'll need to add Upgrade notes for trunk since this might not 
> always be a desired behavior as well as CHANGES notes throughout to indicate 
> the new option if that's what we settle on.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/configs/sip.conf.sample 412438 
>   /branches/1.8/channels/sip/include/sip.h 412438 
>   /branches/1.8/channels/chan_sip.c 412438 
>   /branches/1.8/CHANGES 412438 
> 
> Diff: https://reviewboard.asterisk.org/r/3447/diff/
> 
> 
> Testing
> ---
> 
> Call from SIP peer A to SIP peer B
> settings for both peers:
> sendrpid = pai
> callerpres = prohib
> 
> 
> Invite sent from Asterisk to the recipient of the call
> --
> Prior to patch:
> 
> Audio is at 19640
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as13075548
> To: 
> Contact: 
> Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380
> Date: Tue, 11 Mar 2014 22:59:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Anonymous" 
> Content-Type: application/sdp
> Content-Length: 276
> 
> v=0
> o=root 473543868 473543868 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 19640 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> 
> 
> After patch:
> 
> Audio is at 11822
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK5d4a7db8;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as181a14e3
> To: 
> Contact: 
> Call-ID: 721bef28208f7633288e929c6e88824e@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380M
> Date: Tue, 11 Mar 2014 22:57:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Goldy Locks" 
> Privacy: id
> Content-Type: application/sdp
> Content-Length: 279
> 
> v=0
> o=root 1606369071 1606369071 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380M
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 11822 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
>

Re: [asterisk-dev] [Code Review] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Joshua Colp]

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



/branches/1.8/channels/chan_sip.c


Where do the anonymous values now get placed into the num/name/domain?


- Joshua Colp


On April 16, 2014, 9:23 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 16, 2014, 9:23 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited for a peer that receives 
> P-Asserted-Identity, the P-Asserted-Identity shouldn't be anonymized, only 
> the normal From/Contact headers would be anonymized. This apparently 
> 
> The obvious method for dealing with this mid-release change is to make the 
> change into an option which defaults off in 1.8-12 while defaulting on in 
> trunk. Also I'll need to add Upgrade notes for trunk since this might not 
> always be a desired behavior as well as CHANGES notes throughout to indicate 
> the new option if that's what we settle on.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/configs/sip.conf.sample 412438 
>   /branches/1.8/channels/sip/include/sip.h 412438 
>   /branches/1.8/channels/chan_sip.c 412438 
>   /branches/1.8/CHANGES 412438 
> 
> Diff: https://reviewboard.asterisk.org/r/3447/diff/
> 
> 
> Testing
> ---
> 
> Call from SIP peer A to SIP peer B
> settings for both peers:
> sendrpid = pai
> callerpres = prohib
> 
> 
> Invite sent from Asterisk to the recipient of the call
> --
> Prior to patch:
> 
> Audio is at 19640
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as13075548
> To: 
> Contact: 
> Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380
> Date: Tue, 11 Mar 2014 22:59:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Anonymous" 
> Content-Type: application/sdp
> Content-Length: 276
> 
> v=0
> o=root 473543868 473543868 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 19640 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> 
> 
> After patch:
> 
> Audio is at 11822
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK5d4a7db8;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as181a14e3
> To: 
> Contact: 
> Call-ID: 721bef28208f7633288e929c6e88824e@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380M
> Date: Tue, 11 Mar 2014 22:57:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Goldy Locks" 
> Privacy: id
> Content-Type: application/sdp
> Content-Length: 279
> 
> v=0
> o=root 1606369071 1606369071 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380M
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 11822 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

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

Re: [asterisk-dev] [Code Review] 3455: testsuite: Add chan_sip tests for sendrpid=pai/rpid tests (baseline and with trust_id_outbound)

[Joshua Colp]

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

Ship it!


Ship It!

- Joshua Colp


On April 16, 2014, 9:08 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3455/
> ---
> 
> (Updated April 16, 2014, 9:08 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, opticron, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Part of the effort going on with https://reviewboard.asterisk.org/r/3447/
> 
> The point of these tests is to establish requirements for developing a patch 
> to deal with the anonymity problems described on the issues. The following 
> charts provide the base expectations:
> 
> for sendrpid=pai:
> 
>   | pres=allowed| pres=prohibited   |
> --+-+---+
> trust_id_outbound=no  | PAI: 123, Privacy: none |   |
> --+-+---+
> trust_id_outbound=yes | PAI: 123, Privacy: none | PAI: 123, Privacy: id |
> --+-+---+
> 
> *PAI is abbreviated a bit in this chart
> 
> 
> for sendrpid=rpid:
>   | pres=allowed  
>| pres=prohibited  
>|
> --+--+-+
> trust_id_outbound=no  | Remote-Party-ID: "123" 
> ;party=calling;privacy=off;screen=no | 
> Remote-Party-ID: "123" 
> party=calling;privacy=full;screen=yes |
> --+--+-+
> trust_id_outbound=yes | Remote-Party-ID: "123" 
> ;party=calling;privacy=off;screen=no | 
> Remote-Party-ID: "123" 
> ;party=calling;privacy=full;screen=yes  |
> --+--+-+
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/channels/SIP/tests.yaml 4958 
>   /asterisk/trunk/tests/channels/SIP/sendrpid/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/tests.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/sipp/send.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/sipp/receive.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/configs/ast1/sip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/sipp/send.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/sipp/receive.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/configs/ast1/sip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/tests.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/sipp/send.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/sipp/receive.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/configs/ast1/sip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asteri

Re: [asterisk-dev] [Code Review] 3348: Test Suite: MWI subscription test for PJSIP

[jbigelow]

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

(Updated April 16, 2014, 4:46 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 4961


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


Repository: testsuite


Description
---

This test depends on some changes in the PJSIP python library pjsua.py. The 
plan is to submit this upstream. See in-line with this description below.

This basic nominal test ensures that a mailbox on an AOR for an enpoint can be 
subscribed to for MWI and that a NOTIFY is received. It creates endpoint 
"alice" with subscribing to MWI. Upon receiving a notify for message summary 
indicating no messages the test will be marked as passed otherwise it will be 
failed.

The other two tests on ASTERISK-23343 aren't currently possible with the PJSUA 
API v1 and are up for review at https://reviewboard.asterisk.org/r/3354/ with 
using SIPp.

Note: the following patch for pjsua.py adds modify_account() which isn't 
currently used by the testsuite but was added for possible future use.

Index: pjsip-apps/src/python/pjsua.py
===
--- pjsip-apps/src/python/pjsua.py  (revision 4791)
+++ pjsip-apps/src/python/pjsua.py  (working copy)
@@ -775,6 +775,7 @@
 use_srtp = 0
 srtp_secure_signaling = 1
 rtp_transport_cfg = None
+mwi_enabled = False
 
 def __init__(self, domain="", username="", password="", 
  display="", registrar="", proxy=""):
@@ -865,6 +866,7 @@
 self.ka_data = cfg.ka_data
 self.use_srtp = cfg.use_srtp
 self.srtp_secure_signaling = cfg.srtp_secure_signaling
+self.mwi_enabled = cfg.mwi_enabled
 if (self.rtp_transport_cfg is not None):
 self.rtp_transport_cfg._cvt_from_pjsua(cfg.rtp_transport_cfg)
 
@@ -896,6 +898,7 @@
 cfg.ka_data = self.ka_data
 cfg.use_srtp = self.use_srtp
 cfg.srtp_secure_signaling = self.srtp_secure_signaling
+cfg.mwi_enabled = self.mwi_enabled
 
 if (self.rtp_transport_cfg is not None):
 cfg.rtp_transport_cfg = self.rtp_transport_cfg._cvt_to_pjsua()
@@ -2337,6 +2340,18 @@
 self._err_check("create_account_for_transport()", self, err)
 return Account(self, acc_id, cb)
 
+def modify_account(self, acc_id, acc_config):
+"""Modify configuration of a pjsua account.
+
+Keyword arguments:
+acc_id  -- ID of the account to be modified.
+acc_config  -- New account configuration.
+
+"""
+lck = self.auto_lock()
+err = _pjsua.acc_modify(acc_id, acc_config._cvt_to_pjsua())
+self._err_check("modify_account()", self, err)
+
 def hangup_all(self):
 """Hangup all calls.


Diffs
-

  /asterisk/trunk/tests/channels/pjsip/subscriptions/mwi/tests.yaml 4836 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/mwi/basic_mailbox_subscribe/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/mwi/basic_mailbox_subscribe/subscribe.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/mwi/basic_mailbox_subscribe/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/mwi/basic_mailbox_subscribe/configs/ast1/modules.conf
 PRE-CREATION 
  /asterisk/trunk/lib/python/asterisk/pjsua_mod.py 4836 

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


Testing
---

* Ensured tests pass on multiple executions
* Ensured the testsuite & Asterisk logs looked good.


Thanks,

jbigelow

-- 
_
-- 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] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Jonathan Rose]

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



/branches/1.8/channels/chan_sip.c


I'm slightly iffy on this. Without making this change, the fromdomain would 
always be an anonymized address for callingpres=prohib in the tests that I 
wrote.  Previously this wasn't needed when I was doing a test by hand for 
rpid=pai using phones that registered dynamically.


- Jonathan Rose


On April 16, 2014, 4:23 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 16, 2014, 4:23 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited for a peer that receives 
> P-Asserted-Identity, the P-Asserted-Identity shouldn't be anonymized, only 
> the normal From/Contact headers would be anonymized. This apparently 
> 
> The obvious method for dealing with this mid-release change is to make the 
> change into an option which defaults off in 1.8-12 while defaulting on in 
> trunk. Also I'll need to add Upgrade notes for trunk since this might not 
> always be a desired behavior as well as CHANGES notes throughout to indicate 
> the new option if that's what we settle on.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/configs/sip.conf.sample 412438 
>   /branches/1.8/channels/sip/include/sip.h 412438 
>   /branches/1.8/channels/chan_sip.c 412438 
>   /branches/1.8/CHANGES 412438 
> 
> Diff: https://reviewboard.asterisk.org/r/3447/diff/
> 
> 
> Testing
> ---
> 
> Call from SIP peer A to SIP peer B
> settings for both peers:
> sendrpid = pai
> callerpres = prohib
> 
> 
> Invite sent from Asterisk to the recipient of the call
> --
> Prior to patch:
> 
> Audio is at 19640
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as13075548
> To: 
> Contact: 
> Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380
> Date: Tue, 11 Mar 2014 22:59:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Anonymous" 
> Content-Type: application/sdp
> Content-Length: 276
> 
> v=0
> o=root 473543868 473543868 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 19640 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> 
> 
> After patch:
> 
> Audio is at 11822
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK5d4a7db8;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as181a14e3
> To: 
> Contact: 
> Call-ID: 721bef28208f7633288e929c6e88824e@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380M
> Date: Tue, 11 Mar 2014 22:57:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Goldy Locks" 
> Privacy: id
> Content-Type: application/sdp
> Content-Length: 279
> 
> v=0
> o=root 1606369071 1606369071 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380M
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 11822 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSup

Re: [asterisk-dev] [Code Review] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Jonathan Rose]

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

(Updated April 16, 2014, 4:23 p.m.)


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


Changes
---

The new patch takes some influence from 
https://reviewboard.asterisk.org/r/1803/ and is tested to meet the requirements 
described in the charts on https://reviewboard.asterisk.org/r/3455/


Bugs: AST-1301 and ASTERISK-19465
https://issues.asterisk.org/jira/browse/AST-1301
https://issues.asterisk.org/jira/browse/ASTERISK-19465


Repository: Asterisk


Description
---

Walter Doekes pointed out that this might cause a less than ideal situation in 
which people who were expecting P-Asserted-Identity not to disclose party 
information will now be sending privacy information, so I pulled this patch 
from 1.8-trunk and we will now review it here.

Without this patch, P-Asserted-Identity would always use anonymous for the 
caller ID information, and RFC-3325 seems to indicate that P-Asserted-Identity 
is something that should not be anonymized, but also only sent to trusted 
parties. The way this was presented to me, the intent here is that if you set 
callerpres to prohibited for a peer that receives P-Asserted-Identity, the 
P-Asserted-Identity shouldn't be anonymized, only the normal From/Contact 
headers would be anonymized. This apparently 

The obvious method for dealing with this mid-release change is to make the 
change into an option which defaults off in 1.8-12 while defaulting on in 
trunk. Also I'll need to add Upgrade notes for trunk since this might not 
always be a desired behavior as well as CHANGES notes throughout to indicate 
the new option if that's what we settle on.


Diffs (updated)
-

  /branches/1.8/configs/sip.conf.sample 412438 
  /branches/1.8/channels/sip/include/sip.h 412438 
  /branches/1.8/channels/chan_sip.c 412438 
  /branches/1.8/CHANGES 412438 

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


Testing
---

Call from SIP peer A to SIP peer B
settings for both peers:
sendrpid = pai
callerpres = prohib


Invite sent from Asterisk to the recipient of the call
--
Prior to patch:

Audio is at 19640
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 10.24.18.240:5060:
INVITE sip:123@10.24.18.240:5060 SIP/2.0
Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
Max-Forwards: 70
From: "Anonymous" ;tag=as13075548
To: 
Contact: 
Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX SVN-branch-1.8-r410380
Date: Tue, 11 Mar 2014 22:59:39 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
PUBLISH
Supported: replaces, timer
P-Asserted-Identity: "Anonymous" 
Content-Type: application/sdp
Content-Length: 276

v=0
o=root 473543868 473543868 IN IP4 10.24.18.246
s=Asterisk PBX SVN-branch-1.8-r410380
c=IN IP4 10.24.18.246
t=0 0
m=audio 19640 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv


After patch:

Audio is at 11822
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 10.24.18.240:5060:
INVITE sip:123@10.24.18.240:5060 SIP/2.0
Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK5d4a7db8;rport
Max-Forwards: 70
From: "Anonymous" ;tag=as181a14e3
To: 
Contact: 
Call-ID: 721bef28208f7633288e929c6e88824e@10.24.18.246:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX SVN-branch-1.8-r410380M
Date: Tue, 11 Mar 2014 22:57:39 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
PUBLISH
Supported: replaces, timer
P-Asserted-Identity: "Goldy Locks" 
Privacy: id
Content-Type: application/sdp
Content-Length: 279

v=0
o=root 1606369071 1606369071 IN IP4 10.24.18.246
s=Asterisk PBX SVN-branch-1.8-r410380M
c=IN IP4 10.24.18.246
t=0 0
m=audio 11822 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv


Thanks,

Jonathan Rose

-- 
_
-- 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] 3455: testsuite: Add chan_sip tests for sendrpid=pai/rpid tests (baseline and with trust_id_outbound)

[Jonathan Rose]

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

Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
Michelson, opticron, and wdoekes.


Bugs: AST-1301 and ASTERISK-19465
https://issues.asterisk.org/jira/browse/AST-1301
https://issues.asterisk.org/jira/browse/ASTERISK-19465


Repository: testsuite


Description
---

Part of the effort going on with https://reviewboard.asterisk.org/r/3447/

The point of these tests is to establish requirements for developing a patch to 
deal with the anonymity problems described on the issues. The following charts 
provide the base expectations:

for sendrpid=pai:

  | pres=allowed| pres=prohibited   |
--+-+---+
trust_id_outbound=no  | PAI: 123, Privacy: none |   |
--+-+---+
trust_id_outbound=yes | PAI: 123, Privacy: none | PAI: 123, Privacy: id |
--+-+---+

*PAI is abbreviated a bit in this chart


for sendrpid=rpid:
  | pres=allowed
 | pres=prohibited  
   |
--+--+-+
trust_id_outbound=no  | Remote-Party-ID: "123" 
;party=calling;privacy=off;screen=no | 
Remote-Party-ID: "123" 
party=calling;privacy=full;screen=yes |
--+--+-+
trust_id_outbound=yes | Remote-Party-ID: "123" 
;party=calling;privacy=off;screen=no | 
Remote-Party-ID: "123" 
;party=calling;privacy=full;screen=yes  |
--+--+-+


Diffs
-

  /asterisk/trunk/tests/channels/SIP/tests.yaml 4958 
  /asterisk/trunk/tests/channels/SIP/sendrpid/tests.yaml PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/tests.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/sipp/send.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/sipp/receive.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/configs/ast1/sip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_prohib/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/sipp/send.xml 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/sipp/receive.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/configs/ast1/sip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/trust/pres_allow/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/tests.yaml PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/tests.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/sipp/send.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/sipp/receive.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/configs/ast1/sip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_prohib/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_allow/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_allow/sipp/send.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_allow/sipp/receive.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_allow/configs/ast1/sip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/SIP/sendrpid/rpid/baseline/pres_allow/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/channels/SIP/sendrpid/pai/trust/tests.yaml PR

Re: [asterisk-dev] [Code Review] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Jonathan Rose]

> On April 16, 2014, 2:37 p.m., Jonathan Rose wrote:
> > Hey wdoekes, I'm trying to figure out a similar chart for sendrpid=rpid
> > 
> >   | pres=allowed
> >  | pres=prohibited  
> >|
> > --+--+-+
> > trust_id_outbound=no  | Remote-Party-ID: "123" 
> > ;party=calling;privacy=off;screen=no | 
> > Remote-Party-ID: "123" 
> > party=calling;privacy=full;screen=yes |
> > --+--+-+
> > trust_id_outbound=yes | Remote-Party-ID: "123" 
> > ;party=calling;privacy=off;screen=no | 
> > Remote-Party-ID: "123" 
> > ;party=calling;privacy=full;screen=yes  |
> > --+--+-+
> > 
> > Does that look about like what you would expect? This is keeping in mind 
> > that the trust_id_outbound=no row mirrors the current expectations.
> 
> jamuel wrote:
> For the sake of clarity would you guys mind adding a From column so that 
> we could see how the From header might or might not be mangled based on the 
> various use cases since that's where callerid is found typically?

The From: header should be completely unimpacted by these changes.


- Jonathan


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


On April 16, 2014, 10:16 a.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 16, 2014, 10:16 a.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited for a peer that receives 
> P-Asserted-Identity, the P-Asserted-Identity shouldn't be anonymized, only 
> the normal From/Contact headers would be anonymized. This apparently 
> 
> The obvious method for dealing with this mid-release change is to make the 
> change into an option which defaults off in 1.8-12 while defaulting on in 
> trunk. Also I'll need to add Upgrade notes for trunk since this might not 
> always be a desired behavior as well as CHANGES notes throughout to indicate 
> the new option if that's what we settle on.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/configs/sip.conf.sample 412331 
>   /branches/1.8/channels/chan_sip.c 412331 
> 
> Diff: https://reviewboard.asterisk.org/r/3447/diff/
> 
> 
> Testing
> ---
> 
> Call from SIP peer A to SIP peer B
> settings for both peers:
> sendrpid = pai
> callerpres = prohib
> 
> 
> Invite sent from Asterisk to the recipient of the call
> --
> Prior to patch:
> 
> Audio is at 19640
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as13075548
> To: 
> Contact: 
> Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380
> Date: Tue, 11 Mar 2014 22:59:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Anonymous" 
> Content-Type: application/sdp
> Content-Le

Re: [asterisk-dev] [Code Review] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[jamuel]

> On April 16, 2014, 7:37 p.m., Jonathan Rose wrote:
> > Hey wdoekes, I'm trying to figure out a similar chart for sendrpid=rpid
> > 
> >   | pres=allowed
> >  | pres=prohibited  
> >|
> > --+--+-+
> > trust_id_outbound=no  | Remote-Party-ID: "123" 
> > ;party=calling;privacy=off;screen=no | 
> > Remote-Party-ID: "123" 
> > party=calling;privacy=full;screen=yes |
> > --+--+-+
> > trust_id_outbound=yes | Remote-Party-ID: "123" 
> > ;party=calling;privacy=off;screen=no | 
> > Remote-Party-ID: "123" 
> > ;party=calling;privacy=full;screen=yes  |
> > --+--+-+
> > 
> > Does that look about like what you would expect? This is keeping in mind 
> > that the trust_id_outbound=no row mirrors the current expectations.

For the sake of clarity would you guys mind adding a From column so that we 
could see how the From header might or might not be mangled based on the 
various use cases since that's where callerid is found typically?


- jamuel


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


On April 16, 2014, 3:16 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 16, 2014, 3:16 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited for a peer that receives 
> P-Asserted-Identity, the P-Asserted-Identity shouldn't be anonymized, only 
> the normal From/Contact headers would be anonymized. This apparently 
> 
> The obvious method for dealing with this mid-release change is to make the 
> change into an option which defaults off in 1.8-12 while defaulting on in 
> trunk. Also I'll need to add Upgrade notes for trunk since this might not 
> always be a desired behavior as well as CHANGES notes throughout to indicate 
> the new option if that's what we settle on.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/configs/sip.conf.sample 412331 
>   /branches/1.8/channels/chan_sip.c 412331 
> 
> Diff: https://reviewboard.asterisk.org/r/3447/diff/
> 
> 
> Testing
> ---
> 
> Call from SIP peer A to SIP peer B
> settings for both peers:
> sendrpid = pai
> callerpres = prohib
> 
> 
> Invite sent from Asterisk to the recipient of the call
> --
> Prior to patch:
> 
> Audio is at 19640
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as13075548
> To: 
> Contact: 
> Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380
> Date: Tue, 11 Mar 2014 22:59:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Anonymous" 
> Content-Type: application/sdp
> Content-Length: 276
> 
> v=0
> o=root 473543868 473543868 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-

Re: [asterisk-dev] [Code Review] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Jonathan Rose]

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


Hey wdoekes, I'm trying to figure out a similar chart for sendrpid=rpid

  | pres=allowed
 | pres=prohibited  
   |
--+--+-+
trust_id_outbound=no  | Remote-Party-ID: "123" 
;party=calling;privacy=off;screen=no | 
Remote-Party-ID: "123" 
party=calling;privacy=full;screen=yes |
--+--+-+
trust_id_outbound=yes | Remote-Party-ID: "123" 
;party=calling;privacy=off;screen=no | 
Remote-Party-ID: "123" 
;party=calling;privacy=full;screen=yes  |
--+--+-+

Does that look about like what you would expect? This is keeping in mind that 
the trust_id_outbound=no row mirrors the current expectations.

- Jonathan Rose


On April 16, 2014, 10:16 a.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 16, 2014, 10:16 a.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301 and ASTERISK-19465
> https://issues.asterisk.org/jira/browse/AST-1301
> https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited for a peer that receives 
> P-Asserted-Identity, the P-Asserted-Identity shouldn't be anonymized, only 
> the normal From/Contact headers would be anonymized. This apparently 
> 
> The obvious method for dealing with this mid-release change is to make the 
> change into an option which defaults off in 1.8-12 while defaulting on in 
> trunk. Also I'll need to add Upgrade notes for trunk since this might not 
> always be a desired behavior as well as CHANGES notes throughout to indicate 
> the new option if that's what we settle on.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/configs/sip.conf.sample 412331 
>   /branches/1.8/channels/chan_sip.c 412331 
> 
> Diff: https://reviewboard.asterisk.org/r/3447/diff/
> 
> 
> Testing
> ---
> 
> Call from SIP peer A to SIP peer B
> settings for both peers:
> sendrpid = pai
> callerpres = prohib
> 
> 
> Invite sent from Asterisk to the recipient of the call
> --
> Prior to patch:
> 
> Audio is at 19640
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Transmitting (NAT) to 10.24.18.240:5060:
> INVITE sip:123@10.24.18.240:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
> Max-Forwards: 70
> From: "Anonymous" ;tag=as13075548
> To: 
> Contact: 
> Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX SVN-branch-1.8-r410380
> Date: Tue, 11 Mar 2014 22:59:39 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH
> Supported: replaces, timer
> P-Asserted-Identity: "Anonymous" 
> Content-Type: application/sdp
> Content-Length: 276
> 
> v=0
> o=root 473543868 473543868 IN IP4 10.24.18.246
> s=Asterisk PBX SVN-branch-1.8-r410380
> c=IN IP4 10.24.18.246
> t=0 0
> m=audio 19640 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=sendrecv
> 
> 
> After patch:
> 
> Audio is at 11822
> Adding codec 0x4 (ulaw) to SDP
> Adding non-codec 0x1 (telephone-event) to SDP
> Reliably Tra

Re: [asterisk-dev] [Code Review] 3450: Stasis: Ensure control's bridge pointer has a ref

[opticron]

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

(Updated April 16, 2014, 2:14 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 412439


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


Repository: Asterisk


Description
---

This patch ensures that the Stasis control structure holds a reference to the 
bridge the channel is in so that the pointer does not become stale. This also 
introduces a new function for use cases that only need to check that the 
channel is in a bridge and have no need for the bridge itself since 
stasis_app_get_bridge now bumps the bridge's refcount when returning it.


Diffs
-

  branches/12/res/stasis/control.c 412426 
  branches/12/res/res_stasis_recording.c 412426 
  branches/12/res/res_stasis.c 412426 
  branches/12/res/ari/resource_bridges.c 412426 
  branches/12/include/asterisk/stasis_app.h 412426 

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


Testing
---


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] 3450: Stasis: Ensure control's bridge pointer has a ref

[opticron]

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

(Updated April 16, 2014, 1:05 p.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

This patch ensures that the Stasis control structure holds a reference to the 
bridge the channel is in so that the pointer does not become stale. This also 
introduces a new function for use cases that only need to check that the 
channel is in a bridge and have no need for the bridge itself since 
stasis_app_get_bridge now bumps the bridge's refcount when returning it.


Diffs
-

  branches/12/res/stasis/control.c 412426 
  branches/12/res/res_stasis_recording.c 412426 
  branches/12/res/res_stasis.c 412426 
  branches/12/res/ari/resource_bridges.c 412426 
  branches/12/include/asterisk/stasis_app.h 412426 

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


Testing
---


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] 3313: Testsuite: Convert YAML Configuration Into Call File and Execute

[Scott Emidy]

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

(Updated April 16, 2014, 11:23 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 4958


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


Repository: testsuite


Description
---

This test uses the Pluggable Module Framework in order to convert a YAML 
configuration into an executable Call File by putting it into the correct 
directory, which is the 'astspooldir' directory.


Diffs
-

  ./asterisk/trunk/tests/pbx/tests.yaml 4726 
  ./asterisk/trunk/tests/pbx/create_call_files/test-config.yaml PRE-CREATION 
  ./asterisk/trunk/tests/pbx/create_call_files/configs/ast1/extensions.conf 
PRE-CREATION 
  ./asterisk/trunk/sample-yaml/callfiles-config.yaml.sample PRE-CREATION 
  ./asterisk/trunk/lib/python/asterisk/pluggable_modules.py 4726 

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


Testing
---


Thanks,

Scott Emidy

-- 
_
-- 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] 3313: Testsuite: Convert YAML Configuration Into Call File and Execute

[Scott Emidy]

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

(Updated April 16, 2014, 4:14 p.m.)


Review request for Asterisk Developers.


Changes
---

Fixed the minversion to 1.8.0.0 after all.


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


Repository: testsuite


Description
---

This test uses the Pluggable Module Framework in order to convert a YAML 
configuration into an executable Call File by putting it into the correct 
directory, which is the 'astspooldir' directory.


Diffs (updated)
-

  ./asterisk/trunk/tests/pbx/tests.yaml 4726 
  ./asterisk/trunk/tests/pbx/create_call_files/test-config.yaml PRE-CREATION 
  ./asterisk/trunk/tests/pbx/create_call_files/configs/ast1/extensions.conf 
PRE-CREATION 
  ./asterisk/trunk/sample-yaml/callfiles-config.yaml.sample PRE-CREATION 
  ./asterisk/trunk/lib/python/asterisk/pluggable_modules.py 4726 

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


Testing
---


Thanks,

Scott Emidy

-- 
_
-- 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] 3450: Stasis: Ensure control's bridge pointer has a ref

[opticron]

> On April 15, 2014, 4:45 p.m., Matt Jordan wrote:
> > I know I was thinking that this would be necessary everywhere; it may still 
> > be.
> > 
> > However, when I wrote that particular bug report, we were still having 
> > crashes with reference counting issues in the main Stasis application loop. 
> > Your previous commits fixed that.
> > 
> > While I dislike our current mechanism of tracking the bridge, I also don't 
> > want to make the reference counting issue more confusing than it already 
> > is. Is this patch still necessary? Do we feel that there are situations 
> > when a control structure has a pointer to a bridge but the bridge has been 
> > disposed of by some one else?

All usages other than the one that is already fixed are a check to see whether 
the control is associated with any bridge or specific bridge and do not pose a 
stale pointer risk.

The only risk is new consumers of stasis_app_get_bridge and in this case, I 
would be satisfied with a header documentation change since the scope is fairly 
small.


- opticron


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


On April 15, 2014, 4:09 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3450/
> ---
> 
> (Updated April 15, 2014, 4:09 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23588
> https://issues.asterisk.org/jira/browse/ASTERISK-23588
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch ensures that the Stasis control structure holds a reference to the 
> bridge the channel is in so that the pointer does not become stale. This also 
> introduces a new function for use cases that only need to check that the 
> channel is in a bridge and have no need for the bridge itself since 
> stasis_app_get_bridge now bumps the bridge's refcount when returning it.
> 
> 
> Diffs
> -
> 
>   branches/12/res/stasis/control.c 412426 
>   branches/12/res/res_stasis_recording.c 412426 
>   branches/12/res/res_stasis.c 412426 
>   branches/12/res/ari/resource_bridges.c 412426 
>   branches/12/include/asterisk/stasis_app.h 412426 
> 
> Diff: https://reviewboard.asterisk.org/r/3450/diff/
> 
> 
> Testing
> ---
> 
> 
> 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] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[Jonathan Rose]

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

(Updated April 16, 2014, 10:16 a.m.)


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


Changes
---

Linking ASTERISK-19465


Bugs: AST-1301 and ASTERISK-19465
https://issues.asterisk.org/jira/browse/AST-1301
https://issues.asterisk.org/jira/browse/ASTERISK-19465


Repository: Asterisk


Description
---

Walter Doekes pointed out that this might cause a less than ideal situation in 
which people who were expecting P-Asserted-Identity not to disclose party 
information will now be sending privacy information, so I pulled this patch 
from 1.8-trunk and we will now review it here.

Without this patch, P-Asserted-Identity would always use anonymous for the 
caller ID information, and RFC-3325 seems to indicate that P-Asserted-Identity 
is something that should not be anonymized, but also only sent to trusted 
parties. The way this was presented to me, the intent here is that if you set 
callerpres to prohibited for a peer that receives P-Asserted-Identity, the 
P-Asserted-Identity shouldn't be anonymized, only the normal From/Contact 
headers would be anonymized. This apparently 

The obvious method for dealing with this mid-release change is to make the 
change into an option which defaults off in 1.8-12 while defaulting on in 
trunk. Also I'll need to add Upgrade notes for trunk since this might not 
always be a desired behavior as well as CHANGES notes throughout to indicate 
the new option if that's what we settle on.


Diffs
-

  /branches/1.8/configs/sip.conf.sample 412331 
  /branches/1.8/channels/chan_sip.c 412331 

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


Testing
---

Call from SIP peer A to SIP peer B
settings for both peers:
sendrpid = pai
callerpres = prohib


Invite sent from Asterisk to the recipient of the call
--
Prior to patch:

Audio is at 19640
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 10.24.18.240:5060:
INVITE sip:123@10.24.18.240:5060 SIP/2.0
Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
Max-Forwards: 70
From: "Anonymous" ;tag=as13075548
To: 
Contact: 
Call-ID: 762b8a5e5848d7997f38f71a770d4dd9@10.24.18.246:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX SVN-branch-1.8-r410380
Date: Tue, 11 Mar 2014 22:59:39 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
PUBLISH
Supported: replaces, timer
P-Asserted-Identity: "Anonymous" 
Content-Type: application/sdp
Content-Length: 276

v=0
o=root 473543868 473543868 IN IP4 10.24.18.246
s=Asterisk PBX SVN-branch-1.8-r410380
c=IN IP4 10.24.18.246
t=0 0
m=audio 19640 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv


After patch:

Audio is at 11822
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 10.24.18.240:5060:
INVITE sip:123@10.24.18.240:5060 SIP/2.0
Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK5d4a7db8;rport
Max-Forwards: 70
From: "Anonymous" ;tag=as181a14e3
To: 
Contact: 
Call-ID: 721bef28208f7633288e929c6e88824e@10.24.18.246:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX SVN-branch-1.8-r410380M
Date: Tue, 11 Mar 2014 22:57:39 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
PUBLISH
Supported: replaces, timer
P-Asserted-Identity: "Goldy Locks" 
Privacy: id
Content-Type: application/sdp
Content-Length: 279

v=0
o=root 1606369071 1606369071 IN IP4 10.24.18.246
s=Asterisk PBX SVN-branch-1.8-r410380M
c=IN IP4 10.24.18.246
t=0 0
m=audio 11822 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv


Thanks,

Jonathan Rose

-- 
_
-- 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] 3428: Testsuite: ARI Playback Tones tests for channels and bridges

[Matt Jordan]

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


Add an iteration to one of the existing tests or a separate test that covers 
specifying the tonezone.

- Matt Jordan


On April 8, 2014, 6 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3428/
> ---
> 
> (Updated April 8, 2014, 6 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23433
> https://issues.asterisk.org/jira/browse/ASTERISK-23433
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> The YAML files have pretty apt descriptions.
> 
> Channel version:
> * Originate a channel
> * Playback a tone
> * Pause it
> * Unpause it
> * Restart it
> * Delete the tone playback
> * Delete the channel
> * Validate all the events
> 
> Bridge version:
> * Originate a channel
> * Create a bridge
> * Add the channel to the bridge
> * Start a tone playback on the bridge
> * Delete the tone playback
> * Delete the channel
> * Validate all the events
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/rest_api/playback/tones/test-config.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/playback/tones/configs/ast1/extensions.conf 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/playback/tests.yaml 4944 
>   /asterisk/trunk/tests/rest_api/bridges/tests.yaml 4944 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tones/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/bridges/playback/tones/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tones/bridges_play.py 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/bridges/playback/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/bridges/bridge_play/test-config.yaml 4944 
>   
> /asterisk/trunk/tests/rest_api/bridges/bridge_play/configs/ast1/extensions.conf
>  4944 
>   /asterisk/trunk/tests/rest_api/bridges/bridge_play/bridges_play.py 4944 
> 
> Diff: https://reviewboard.asterisk.org/r/3428/diff/
> 
> 
> Testing
> ---
> 
> Ran tests, varied results, the usual.  They aren't especially changed from 
> the tests they are based on (in each case there is an existing baseline test 
> in the same folder which handles sounds).
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

-- 
_
-- 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] 3427: ARI: Add tones playback resource

[Matt Jordan]

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

Ship it!


The tests that have been written should also include a case where they pass a 
tone with a tonezone in the URI.

- Matt Jordan


On April 15, 2014, 5:25 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3427/
> ---
> 
> (Updated April 15, 2014, 5:25 p.m.)
> 
> 
> Review request for Asterisk Developers, David Lee, Joshua Colp, and Matt 
> Jordan.
> 
> 
> Bugs: ASTERISK-23433
> https://issues.asterisk.org/jira/browse/ASTERISK-23433
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Adds a tones URI type to the playback resource. The tone can be specified by 
> name (from indications.conf) or by a tone pattern (comma separate 
> pitch/duration list). Tones aren't like regular sounds in that they must be 
> canceled manually before the control can move on to the next item in the 
> queue.
> 
> Tones are capable of being paused and resumed (although they will always 
> resumed from the beginning of the tone), restarted, and stopped.  Tones are 
> not capable of being fastforwarded, skipped into by a duration, or rewound by 
> a small amount. Those operations unfortunately report success rather than a 
> lack of availability right now due to how control on playbacks is defined (a 
> playback is either completely controllable or not). I could probably add a 
> little more granularity to that if we want it.
> 
> 
> Diffs
> -
> 
>   /branches/12/rest-api/api-docs/channels.json 412426 
>   /branches/12/rest-api/api-docs/bridges.json 412426 
>   /branches/12/res/res_stasis_playback.c 412426 
>   /branches/12/res/ari/resource_channels.h 412426 
>   /branches/12/res/ari/resource_bridges.h 412426 
>   /branches/12/main/app.c 412426 
>   /branches/12/include/asterisk/app.h 412426 
>   /branches/12/CHANGES 412426 
> 
> Diff: https://reviewboard.asterisk.org/r/3427/diff/
> 
> 
> Testing
> ---
> 
> I've written two testsuite tests (one for channels, one for bridges) which 
> queue and stop tones with playback. I'll be posting them before too long.  
> I've also performed all the basic control operations by hand.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

-- 
_
-- 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] 3451: app_dial and app_queue: Make lock the forwarding channel while taking the channel snapshot.

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On April 15, 2014, 9:05 p.m., rmudgett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3451/
> ---
> 
> (Updated April 15, 2014, 9:05 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> * Fixed ast_channel_publish_dial_forward() not locking the forwarded channel 
> when taking the channel snapshot.
> 
> * Fixed app_dial.c:do_forward() using the wrong channel to get the original 
> call forwarding string.
> 
> * Removed unnecessary locking when calling ast_channel_publish_dial() and 
> ast_channel_publish_dial_forward() in app_dial and app_queue.  Holding 
> channel locks when calling ast_channel_publish_dial_forward() with a 
> forwarded channel could result in pausing the system while the stasis bus 
> completes processsing a forwarded channel subscription.
> 
> 
> Diffs
> -
> 
>   /branches/12/main/stasis_channels.c 412438 
>   /branches/12/apps/app_queue.c 412438 
>   /branches/12/apps/app_dial.c 412438 
> 
> Diff: https://reviewboard.asterisk.org/r/3451/diff/
> 
> 
> Testing
> ---
> 
> Dialed a number that redirected the call to a new number.  Call still went 
> were expected.
> 
> 
> 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] 3454: When Asterisk initiates an ICE-based session, then it must send it's STUN check messages using role "ICE-CONTROLLING". Currently it uses "ICE-CONTROLLED". Though

[Matt Jordan]

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



http://svn.asterisk.org/svn/asterisk/trunk/res/res_rtp_asterisk.c


This is going to make Asterisk always assume that it is the controlling 
session, which is incorrect.

If the UNKNOWN role is not sufficient, then the signature of ice_create 
would have to change to know whether or not Asterisk is creating the ICE 
session for an offer or for an answer. That information has to be passed down 
to res_rtp_asterisk from whatever is creating the RTP instance.


- Matt Jordan


On April 16, 2014, 3:43 a.m., Marko Seidenglanz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3454/
> ---
> 
> (Updated April 16, 2014, 3:43 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23026
> https://issues.asterisk.org/jira/browse/ASTERISK-23026
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> The following patch must be applied to res_rtp_asterisk to make outgoing 
> calls to WebRTC capable browsers working. This is necessary due to the 
> following issue in role negotiation:
> https://code.google.com/p/webrtc/issues/detail?id=2717&can=4&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Area%20Status%20Owner%20Summary
> 
> 
> Diffs
> -
> 
>   http://svn.asterisk.org/svn/asterisk/trunk/res/res_rtp_asterisk.c 412438 
> 
> Diff: https://reviewboard.asterisk.org/r/3454/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marko Seidenglanz
> 
>

-- 
_
-- 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] 3430: [channels/chan_unistim.c]: Improvements and bugfixes to chan_unistim.c

[Peter Whisker]

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

(Updated April 16, 2014, 11:07 a.m.)


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

I have been actively testing Unistim devices (i2002 & i2004) and have 
encountered issues with
1) dialtone wrong
2) inability to select DTMF playback duration
3) inability to set date to match than of a Nortel CS1000
4) mute causing playback to be muted as well as microphone
5) Timer displayed in French (Duree)

The attached patch fixes as follows:
1) The "modulation" should not be referenced for tone+tone as it refers to the 
on-off characteristic I believe - this often resulted in a single tone rather 
than the multitone as in the UK.
2) I have added the unistim.conf variable dtmf_duration which can select the 
DTMF playback duration from 0ms to 150ms (0 is off and is the new default)
3) I have enabled the transmission of MonthLabels (in English) which are sent 
with the date and changed the dateformat variable to accept the values 0-3 as 
per the UNISTIM standard (2 & 3 match the previous 1 & 2 formats).
4) I have enabled the "Mute" packet and merged it into the previous code. It 
now only mutes the microphone. (Improvements welcome)
5) Changed Duree to Timer on i2004 display


Diffs (updated)
-

  /trunk/configs/unistim.conf.sample 412191 
  /trunk/channels/chan_unistim.c 412191 
  /trunk/CHANGES 412191 

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


Testing
---

In use here


Thanks,

Peter Whisker

-- 
_
-- 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] 3439: chan_sip: Support a=rtcp attribute in SDP

[Sean Bright]

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



/trunk/res/res_rtp_asterisk.c


Should this be an 'else if?'  If not it should be on its own line.


- Sean Bright


On April 11, 2014, 1:46 p.m., Olle E Johansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3439/
> ---
> 
> (Updated April 11, 2014, 1:46 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> the A=rtcp attribute in SDP points out a different port than the mediaport+1 
> to receive RTCP on. This patch adds a new api to rtpengine and 
> res_rtp_asterisk and updates chan_sip to use it.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_rtp_asterisk.c 412166 
>   /trunk/main/rtp_engine.c 412166 
>   /trunk/include/asterisk/rtp_engine.h 412166 
>   /trunk/channels/chan_sip.c 412166 
> 
> Diff: https://reviewboard.asterisk.org/r/3439/diff/
> 
> 
> Testing
> ---
> 
> A massive amount of testing with a test tool for interoperability.
> 
> 
> Thanks,
> 
> Olle E Johansson
> 
>

-- 
_
-- 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] 3454: When Asterisk initiates an ICE-based session, then it must send it's STUN check messages using role "ICE-CONTROLLING". Currently it uses "ICE-CONTROLLED". Though the

[Marko Seidenglanz]

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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

The following patch must be applied to res_rtp_asterisk to make outgoing calls 
to WebRTC capable browsers working. This is necessary due to the following 
issue in role negotiation:
https://code.google.com/p/webrtc/issues/detail?id=2717&can=4&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Area%20Status%20Owner%20Summary


Diffs
-

  http://svn.asterisk.org/svn/asterisk/trunk/res/res_rtp_asterisk.c 412438 

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


Testing
---


Thanks,

Marko Seidenglanz

-- 
_
-- 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] 3337: Code for DTLS retransmission

[Nitesh Bansal]

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

(Updated April 16, 2014, 8:26 a.m.)


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

This patch adds the code to do the DTLS retransmissions in Asterisk.


Diffs (updated)
-

  http://svn.asterisk.org/svn/asterisk/branches/11/res/res_rtp_asterisk.c 
412438 

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


Testing
---

I tested this with a basic SIPP script, which fakes a DTLS INVITE.
Asterisk thinks that it is a DTLS call and inititates the DTLS handshake. SIPP 
doesn't respond to DTLS handshake, which causes the DTLS timeout and DTLS 
retransmission takes place.


Thanks,

Nitesh Bansal

-- 
_
-- 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] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[wdoekes]

> On April 15, 2014, 5:15 p.m., Mark Michelson wrote:
> > First off, I agree that anonymizing P-Asserted-Identity is not the correct 
> > way to be going here. The concept of trust is something that is not 
> > well-defined in chan_sip. The closest thing we currently have is the 
> > trustrpid option. When it is set, it means that we will actually use 
> > inbound Remote-Party-ID/P-Asserted-Identity headers as the identity of the 
> > entity that sent the SIP request/response to us.
> > 
> > In chan_pjsip, we have two trust-related options, trust_id_inbound and 
> > trust_id_outbound. trust_id_inbound is pretty much the same as chan_sip's 
> > trustrpid option. trust_id_outbound is a bit different. If set to yes, then 
> > we will send private identity information but include an indication that 
> > the information is private/restricted. In the case of P-Asserted-Identity, 
> > this means that the P-Asserted-Identity header is kept intact and a 
> > Privacy: id header is added. If trust_id_outbound is set to no, then we 
> > will send unrestricted identifying information, but anything marked as 
> > private/restricted does not get sent to the untrusted party at all.
> > 
> > Implementing an option similar to chan_pjsip's trust_id_outbound option is 
> > probably a good way to go. I think that it probably should default to 
> > off/false/no in all versions of Asterisk.
> 
> Jonathan Rose wrote:
> Alright, so if I'm interpreting you correctly here, what you are 
> advocating is this:
> 
> * Add option trust_id_outbound (or similar name) to SIP peers
> when on and sendrpid=pai, include P-Asserted-Identity with legitimate 
> caller ID information as well as 'Privacy: id' header
> when off and sendrpid=pai, don't bother with P-Asserted-Identity because 
> the peer isn't a trusted party
> 
> Maybe I'm a little confused on that second part... What does it mean to 
> send 'unrestricted identifying information' in the case when 
> trust_id_outbound=no?
> 
> Mark Michelson wrote:
> The bullet point is correct, assuming that the information being sent is 
> private/restricted. If the identify is not private/restricted, then the 
> trust_id_outbound option has no bearing on what we send.
> 
> "What does it mean to send 'unrestricted identifying information' in the 
> case when trust_id_outbound=no?"
> 
> When I say unrestricted identifying information, I basically mean private 
> caller ID. I said it the other way because I generally don't like equating 
> the content of P-Asserted-Identity to Caller ID, and the word "unrestricted" 
> just means that it has no privacy or other restrictions applied. So when 
> trust_id_outbound is set to no, then if the caller ID is not private, then 
> we'll go ahead and send it.
> 
> wdoekes wrote:
> This was also already discussed (with various patch attempts) in 
> https://issues.asterisk.org/jira/browse/ASTERISK-19465 (can you link it?).
> 
> What Mark says is this, and that looks sound to me.
> 
>   | pres=allowed| pres=prohibited   |
> --+-+---+
> trust_id_outbound=no  | PAI: 123, Privacy: none |   |
> --+-+---+
> trust_id_outbound=yes | PAI: 123, Privacy: none | PAI: 123, Privacy: id |
> --+-+---+
> 
> Note that you'd want to apply this same behaviour to sendrpid=rpid for 
> consistency, at least in trunk.

Hm, it even has a stale review request: https://reviewboard.asterisk.org/r/1803/


- wdoekes


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


On April 15, 2014, 4:52 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 15, 2014, 4:52 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301
> https://issues.asterisk.org/jira/browse/AST-1301
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is so

Re: [asterisk-dev] [Code Review] 3447: Send real CallerID information with P-Asserted-Identity (RFC-3325)

[wdoekes]

> On April 15, 2014, 5:15 p.m., Mark Michelson wrote:
> > First off, I agree that anonymizing P-Asserted-Identity is not the correct 
> > way to be going here. The concept of trust is something that is not 
> > well-defined in chan_sip. The closest thing we currently have is the 
> > trustrpid option. When it is set, it means that we will actually use 
> > inbound Remote-Party-ID/P-Asserted-Identity headers as the identity of the 
> > entity that sent the SIP request/response to us.
> > 
> > In chan_pjsip, we have two trust-related options, trust_id_inbound and 
> > trust_id_outbound. trust_id_inbound is pretty much the same as chan_sip's 
> > trustrpid option. trust_id_outbound is a bit different. If set to yes, then 
> > we will send private identity information but include an indication that 
> > the information is private/restricted. In the case of P-Asserted-Identity, 
> > this means that the P-Asserted-Identity header is kept intact and a 
> > Privacy: id header is added. If trust_id_outbound is set to no, then we 
> > will send unrestricted identifying information, but anything marked as 
> > private/restricted does not get sent to the untrusted party at all.
> > 
> > Implementing an option similar to chan_pjsip's trust_id_outbound option is 
> > probably a good way to go. I think that it probably should default to 
> > off/false/no in all versions of Asterisk.
> 
> Jonathan Rose wrote:
> Alright, so if I'm interpreting you correctly here, what you are 
> advocating is this:
> 
> * Add option trust_id_outbound (or similar name) to SIP peers
> when on and sendrpid=pai, include P-Asserted-Identity with legitimate 
> caller ID information as well as 'Privacy: id' header
> when off and sendrpid=pai, don't bother with P-Asserted-Identity because 
> the peer isn't a trusted party
> 
> Maybe I'm a little confused on that second part... What does it mean to 
> send 'unrestricted identifying information' in the case when 
> trust_id_outbound=no?
> 
> Mark Michelson wrote:
> The bullet point is correct, assuming that the information being sent is 
> private/restricted. If the identify is not private/restricted, then the 
> trust_id_outbound option has no bearing on what we send.
> 
> "What does it mean to send 'unrestricted identifying information' in the 
> case when trust_id_outbound=no?"
> 
> When I say unrestricted identifying information, I basically mean private 
> caller ID. I said it the other way because I generally don't like equating 
> the content of P-Asserted-Identity to Caller ID, and the word "unrestricted" 
> just means that it has no privacy or other restrictions applied. So when 
> trust_id_outbound is set to no, then if the caller ID is not private, then 
> we'll go ahead and send it.

This was also already discussed (with various patch attempts) in 
https://issues.asterisk.org/jira/browse/ASTERISK-19465 (can you link it?).

What Mark says is this, and that looks sound to me.

  | pres=allowed| pres=prohibited   |
--+-+---+
trust_id_outbound=no  | PAI: 123, Privacy: none |   |
--+-+---+
trust_id_outbound=yes | PAI: 123, Privacy: none | PAI: 123, Privacy: id |
--+-+---+

Note that you'd want to apply this same behaviour to sendrpid=rpid for 
consistency, at least in trunk.


- wdoekes


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


On April 15, 2014, 4:52 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> ---
> 
> (Updated April 15, 2014, 4:52 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Matt Jordan, Mark 
> Michelson, and wdoekes.
> 
> 
> Bugs: AST-1301
> https://issues.asterisk.org/jira/browse/AST-1301
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Walter Doekes pointed out that this might cause a less than ideal situation 
> in which people who were expecting P-Asserted-Identity not to disclose party 
> information will now be sending privacy information, so I pulled this patch 
> from 1.8-trunk and we will now review it here.
> 
> Without this patch, P-Asserted-Identity would always use anonymous for the 
> caller ID information, and RFC-3325 seems to indicate that 
> P-Asserted-Identity is something that should not be anonymized, but also only 
> sent to trusted parties. The way this was presented to me, the intent here is 
> that if you set callerpres to prohibited

Re: [asterisk-dev] [Code Review] 3439: chan_sip: Support a=rtcp attribute in SDP

[Olle E Johansson]

> On April 16, 2014, 2:13 a.m., Corey Farrell wrote:
> > /trunk/channels/chan_sip.c, line 11195
> > 
> >
> > I will not get in the way if this change does not support parsing the 
> > optional address of the rtcp attribute.
> > 
> > For any rtcp attribute where the address is specified, we need to 
> > either parse it or reject the whole attribute and return FALSE.

Good idea, but if you want to change to "rctp:" we will have to change all 
other parts of the code that parses sdp, and that's another patch than his. I 
will follow the rest of the code in this small patch.

I'll check on the address part. I've never seen it around.


- Olle E


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


On April 11, 2014, 3:46 p.m., Olle E Johansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3439/
> ---
> 
> (Updated April 11, 2014, 3:46 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> the A=rtcp attribute in SDP points out a different port than the mediaport+1 
> to receive RTCP on. This patch adds a new api to rtpengine and 
> res_rtp_asterisk and updates chan_sip to use it.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_rtp_asterisk.c 412166 
>   /trunk/main/rtp_engine.c 412166 
>   /trunk/include/asterisk/rtp_engine.h 412166 
>   /trunk/channels/chan_sip.c 412166 
> 
> Diff: https://reviewboard.asterisk.org/r/3439/diff/
> 
> 
> Testing
> ---
> 
> A massive amount of testing with a test tool for interoperability.
> 
> 
> Thanks,
> 
> Olle E Johansson
> 
>

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