[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] [Code Review] 3447: Send real CallerID information with P-Asserted-Identity (RFC-
From: Pavel Troller <patrol () sinus ! cz>
Date: 2014-04-17 17:33:39
Message-ID: 20140417173339.GA14955 () tangens ! sinus ! cz
[Download RAW message or body]
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3447/#review11659
> -----------------------------------------------------------
>
>
> So going with the legacy idea wdoekes posted, I've updated the \
> expectations charts:
> sendrpid=pai
> > pres=allowed | pres=prohibited \
> > ???
> -------------------------+--------------------------------------+----------------------------------------------------???
> trust_id_outbound=legacy | PAI: "123" <sip:123@xxx.xxx.xxx.xxx> | PAI: \
> "anonymous" <sip:anonymous@anonymous.invalid> ???
> -------------------------+--------------------------------------+----------------------------------------------------???
> trust_id_outbound=no | PAI: "123" <sip:123@xxx.xxx.xxx.xxx> | \
> ???
> -------------------------+--------------------------------------+----------------------------------------------------???
> trust_id_outbound=yes | PAI: "123" <sip:123@xxx.xxx.xxx.xxx> | PAI: \
> "123" <sip:123@xxx.xxx.xxx.xxx>, Privacy: id ??? \
> ?????????????????????????????????????????????????????????????????????????? \
> ?????????????????????????????????????????????????????????????????????????? \
> ?????????????????????????????????????????????????????????????????????????? \
> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
>
>
> sendrpid=rpid
> > pres=allowed \
> > | pres=prohibited \
> > ???
> -------------------------+------------------------------------------------ \
> --------------------------------------+------------------------------------------------------------------------------------------???
> trust_id_outbound=legacy | Remote-Party-ID: "123" \
> <sip:123@xxx.xxx.xxx.xxx>;party=calling;privacy=off;screen=no | \
> Remote-Party-ID: "123" \
> <sip:123@anonymous.invalid>;party=calling;privacy=full;screen=yes \
> ???
> -------------------------+------------------------------------------------ \
> --------------------------------------+------------------------------------------------------------------------------------------???
> trust_id_outbound=no | Remote-Party-ID: "123" \
> <sip:123@xxx.xxx.xxx.xxx>;party=calling;privacy=off;screen=no | \
> ???
> -------------------------+------------------------------------------------ \
> --------------------------------------+------------------------------------------------------------------------------------------???
> trust_id_outbound=yes | Remote-Party-ID: "123" \
> <sip:123@xxx.xxx.xxx.xxx>;party=calling;privacy=off;screen=no | \
> Remote-Party-ID: "123" \
> <sip:123@xxx.xxx.xxx.xxx>;party=calling;privacy=full;screen=yes ??? \
> ?????????????????????????????????????????????????????????????????????????? \
> ?????????????????????????????????????????????????????????????????????????? \
> ?????????????????????????????????????????????????????????????????????????? \
> ?????????????????????????????????????????????????????????????????????????? \
> ?????????????????????????????????????????????????????????????????????????? \
> ?????????????????????????????????????????????????????????????????????????? \
> ?????????????????????????????????????????????????????????????????????????? \
> ??????????????????????????????????????????????????????????????????????????????????????????????
>
>
> default setting of trust_id_outbound will be legacy for 1.8-12
> no for trunk
>
> I hope this is all correct...
>
> - Jonathan Rose
>
Hi!
I still don't agree with "screen=" field.
Once again. Generally speaking, the process of "screening" means \
verification of the number, supplied by the caller, against internal \
database provided by the exchange. In the TDM world (ISDN, SS7) it has the \
following values:
- User provided, verified and passed: The number was supplied by the user \
and it passed verification against the system database.
- User provided, not screened: The number was supplied by the user, no
screening has been provided by the exchange.
- System provided: THe number provided by the user (if any) was rejected
during the screening process and replaced by the number provided by the \
internal database of the exchange.
- USA (ANSI version) only: User provided, verified and failed: The number \
provided by the user didn't pass the screening process; however, it was \
not replaced by the system provided one.
In Asterisk, the values stated above are all basically there, but merged
together with the "pres" attribute of the number onto one byte. Please see
asterisk/callerid.h file:
/* Various defines and bits for handling PRI- and SS7-type restriction */
#define AST_PRES_NUMBER_TYPE 0x03
#define AST_PRES_USER_NUMBER_UNSCREENED 0x00
#define AST_PRES_USER_NUMBER_PASSED_SCREEN 0x01
#define AST_PRES_USER_NUMBER_FAILED_SCREEN 0x02
#define AST_PRES_NETWORK_NUMBER 0x03
#define AST_PRES_RESTRICTION 0x60
#define AST_PRES_ALLOWED \
0x00 #define AST_PRES_RESTRICTED \
0x20 #define AST_PRES_UNAVAILABLE 0x40
#define AST_PRES_RESERVED \
0x60
I hope that from my description above, it's clear that SCREENING has \
nothing to do with PRESENTATION. It just shares the same byte in the \
asterisk data structure, but it's a different field for a different \
purpose. So, IMHO, the only valid method of handling the "screen=" tag of \
the RPID header is to read the screening portion (lower byte) of the \
"num-pres" data field, and set it as follows:
AST_PRES_NUMBER_TYPE value screen= value
-----------------------------------------------------
AST_PRES_USER_NUMBER_UNSCREENED screen=no
AST_PRES_USER_NUMBER_PASSED_SCREEN screen=yes
AST_PRES_NETWORK_NUMBER screen=yes
AST_PRES_USER_NUMBER_FAILED_SCREEN screen=no
It's on the dialplan responsibility to use the
Set(CALLERID(num-pres)="whatever") to properly set the screening portion
of the num-pres record. Any forced changes by the channel driver are \
unwanted, as they will prevent proper setting by the advanced dialplan \
logic, thus preventing proper implementation of the signalling details. \
So, please STOP suggesting fixed screen= values, just apply them from the \
callerid data...
Many thanks!
With regards,
Pavel
>
> 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
--
_____________________________________________________________________
-- 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic