> On April 16, 2014, 6:02 p.m., Joshua Colp wrote:
> > /branches/1.8/channels/chan_sip.c, lines 11420-11425
> > <https://reviewboard.asterisk.org/r/3447/diff/2/?file=57476#file57476line11420>
> >
> > If a legit fromdomain is specified you have to use it, or else you've
> > just ignored the fromdomain configuration option.
>
> Jonathan Rose wrote:
> Hmmm. Since that's the case I need to figure out why I was seeing
> anonymous strings here with my test. This scares me a bit since I'm not sure
> how to deal with the anonymous.invalid address I was seeing in my baseline
> test for rpid (sendrpid=rpid, callingpres=prohib)
> Remote-Party-ID: "123"
> <sip:123@anonymous.invalid>party=calling;privacy=full;screen=yes
>
> If I need to send a non-anonymous address when using the
> trust_outbound_id setting, I need a way to get that, and right now it seems
> like one doesn't exist since the fromdomain will be invalid when callingpres
> is a prohibited value.
You know, I suppose since anonymous.invalid and anonymous are at least
predictable, I could just manually check to see if that's what is in fromdomain
after doing
fromdomain = S_OR(p->fromdomain, ast_sockaddr_stringify_host_remote(&p->ourip));
and if that's the case when trust_id_outbound is set, then we reset to
ast_sockaddr_stringify_host_remote... basically turn it into this:
fromdomain = p->fromdomain;
if (!fromdomain || (ast_test_flag(&p->flags[1], SIP_PAGE2_TRUST_ID_OUTBOUND) &&
(strncmp(fromdomain, "anonymous", 9))) {
fromdomain = ast_sockaddr_stringify_host_remote(&p->ourip);
}
Not sure if that seems like an appropriate approach, but it's about all I've
got for now.
I'm loathe to change the behavior of how things are working for sendrpid=rpid,
but it seems apparent now that we would only use an anonymous domain name in my
test for:
| pres=allowed | pres=prohibited
|
----------------------+----------------------------------+-----------------------------------------------------------------------------------------+
trust_id_outbound=no | Remote-Party-ID: "123" <sip... | Remote-Party-ID:
"123" <sip:123@anonymous.invalid>party=calling;privacy=full;screen=yes | <---
This one
----------------------+----------------------------------+-----------------------------------------------------------------------------------------+
trust_id_outbound=yes | Remote-Party-ID: "123" <sip... | Remote-Party-ID:
"123" <sip:1...@xxx.xxx.xxx.xxx>;party=calling;privacy=full;screen=yes |
----------------------+----------------------------------+-----------------------------------------------------------------------------------------+
is because the fromdomain was set to anonymous.invalid by some other mechanism.
It might be the case that we actually need to use a deliberately anonymized
address here, in which case we may need to bring back that anonymous string you
were talking about in the finding below and make use of it here... in which
case maybe we really expect a value of:
Remote-Party-ID: "Anonymous"
<sip:anonymous@anonymous.invalid>;party=calling;privacy=full;screen=yes
- Jonathan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3447/#review11646
-----------------------------------------------------------
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" <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
