> 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 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" <sip:anonymous@anonymous.invalid>;tag=as13075548 > To: <sip:123@10.24.18.240:5060> > Contact: <sip:anonymous@10.24.18.246:5060> > 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" <sip:anonymous@anonymous.invalid> > 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" <sip:anonymous@anonymous.invalid>;tag=as181a14e3 > To: <sip:123@10.24.18.240:5060> > Contact: <sip:anonymous@10.24.18.246:5060> > 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" <sip:6018@10.24.18.246> > 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
