> 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.
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. > On April 16, 2014, 6:02 p.m., Joshua Colp wrote: > > /branches/1.8/channels/chan_sip.c, lines 11430-11438 > > <https://reviewboard.asterisk.org/r/3447/diff/2/?file=57476#file57476line11430> > > > > 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. The anonymous string would only get used under the following conditions: 1. sendrpid mode was pai 2. the lid_pres value was not an 'AST_PRES_ALLOWED' class of callingpres values. Going by the chart for pai that wdoekes suggested: | pres=allowed | pres=prohibited | ----------------------+-------------------------+-----------------------+ trust_id_outbound=no | PAI: 123, Privacy: none | | <-------------- It's this one ----------------------+-------------------------+-----------------------+ trust_id_outbound=yes | PAI: 123, Privacy: none | PAI: 123, Privacy: id | ----------------------+-------------------------+-----------------------+ Then we shouldn't be sending either header in this case, which is why the anonymous string was removed. - 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
