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


Looks mostly good. The documentation could use some tweaking.
And I'm unsure what you did with fromdomain there.


Also, unrelated, your latest chart said this:

> <pps:public> == party=calling;privacy=off;screen=no
> <pps:private> == party=calling;privacy=full;screen=yes

While your comment said this:

> Well, I had no plans of making any changes to how
> party/privacy/screen are set, so he can rest easy on that one.

That did still leave the possibility for extra confusion in this regard.
'screen=whatever' or 'screen=no' in both places would have been more
appropriate. But yes, Pavel can rest easy.


/branches/1.8/CHANGES
<https://reviewboard.asterisk.org/r/3447/#comment21435>

    > By default, legacy is used.
    > trust_id_outbound=legacy: behavior 
    > remains the same as 1.8.26.1 - When
    > dealing with prohibited callingpres, 
    > RPID/PAI headers are created for both
    > sendrpid=pai and sendrpid=rpid are 
    > appended, but the data is anonymized.
    
    sendrpid=rpid + legacy is *not* anonymous, while sendrpid=pai + legacy *is*.
    
    Clarity in here isn't as important to me as clarity in sip.conf though.



/branches/1.8/CHANGES
<https://reviewboard.asterisk.org/r/3447/#comment21434>

    Should this be "chan_sip" changes? Since there is that other driver in 
asterisk 12.



/branches/1.8/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/3447/#comment21438>

    Aren't you altering legacy here?
    
    Previously we would always use host_remote if p->fromdomain was empty. Now 
we only use it when trust_id_outbound=yes.



/branches/1.8/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/3447/#comment21436>

    I'd rather see these two in the same 'if' where the Privacy-id is appended 
in a sub-conditional.
    
    
    if not legacy {
      do stuff
      if privacy {
        add privacy-id
      }
    } else {
      do old legacy stuff
      possibly delete this block in asterisk 14
    }



/branches/1.8/configs/sip.conf.sample
<https://reviewboard.asterisk.org/r/3447/#comment21437>

    in case of PAI, private data will be anonymized (following historic 
behaviour violating RFC-3325)
    
    in case of RPID, this behaves as trust_id_outbound=yes


- wdoekes


On April 17, 2014, 8:25 p.m., Jonathan Rose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/
> -----------------------------------------------------------
> 
> (Updated April 17, 2014, 8:25 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:[email protected]:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK2fb42910;rport
> Max-Forwards: 70
> From: "Anonymous" <sip:[email protected]>;tag=as13075548
> To: <sip:[email protected]:5060>
> Contact: <sip:[email protected]:5060>
> Call-ID: [email protected]: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" <sip:[email protected]>
> 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:[email protected]:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.24.18.246:5060;branch=z9hG4bK5d4a7db8;rport
> Max-Forwards: 70
> From: "Anonymous" <sip:[email protected]>;tag=as181a14e3
> To: <sip:[email protected]:5060>
> Contact: <sip:[email protected]:5060>
> Call-ID: [email protected]: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" <sip:[email protected]>
> 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

Reply via email to