[asterisk-dev] [Code Review] P-Asserted-Identity Privacy - fixed behaviour

[wdoekes]

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


Thanks for posting the patch here. For those who have not read the bugreport, I'll summarize my problems with this patch:

When dealing with peers, some should be allowed to see private/prohibited CLI's (CLIR) and some shouldn't -- sip2pstn links usually should and endusers usually shouldn't. I call these trusted and untrusted, but someone may have a better term form them.

Current behaviour in Asterisk is as follows:
 - sendrpid=no => the peer does *not* get CLIR
 - sendrpid=yes/rpid => the peer *does* get CLIR (with privacy=full tag)
 - sendrpid=pai => the peer does *not* get CLIR (but Anonymous at ...)

Yes, that is inconsistent, but that is the current situation.


What is good about this patch:

- The Privacy header is sent properly. However, IMO, this is only useful for these so-called 'trusted' peers.

- There is now a difference between trust levels.


My problems with this patch:

- It breaks backwards compatibility: sendrpid=pai will show CLIR to anyone.

- There is no way to disable sending of CLIR. When we don't trust the peer, the PAI should not get sent.
  Now, all it does is set From to Anonymous, but still send the CLIR.
   http://tools.ietf.org/html/rfc3325#section-10.2 
   """The next proxy removes the P-Asserted-Identity
   header field and the request for Privacy before forwarding this
   request onward to the biloxi.com proxy server which it does not
   trust."""

- The same goes for RPID, but there CLIR to untrusted peers should probably behave as PAI does now: set Anonymous@ in the header.


I like this fix, but it needs some tweaking IMO.

- wdoekes


On March 6, 2012, 5:16 p.m., jamicque wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1803/
> -----------------------------------------------------------
> 
> (Updated March 6, 2012, 5:16 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> It seams that in Asterisk privacy with PAI is not implemented correctly.
> 
> According to RFC 3325 when using privacy, FROM header should be set to anonymous at anonymous.invalid and PAI header should be set to caller num and name. The privacy is implemented by adding privacy: id header.
> Now when we use pai and callpres=prohib in P-Asserted-Identity header we have something which is not correct to any rfc.
> P-Asserted-Identity: "Anonymous" <sip:anonymous at anonymous.invalid>
> 
> What my patch does:
> 1) it adds Privacy header when PAI is used (values "none" or "id" depending on callpres)
> 2)
> 3) "sendrpid" configuration option have been expanded:
> now it can have those values:
> 
>     no - nothing changed
>     yes - rpid header is added, when call PRES=prohi, FROM header is not changed
>     rpid - the same as yes
>     pai - pai header is added, when call PRES=prohi, FROM header is not changed
> 
> NEW VALUES:
> 
>     rpid,trusted (NEW) - the same as yes
>     rpid,untrusted (NEW) - rpid header is added, when call PRES=prohi, FROM header is chenged to anonymous at anonymous.invalid
>     pai,trusted (NEW) - the same as pai
>     pai,untrusted (NEW) - pai header is added, when call PRES=prohi, FROM header is chenged to anonymous at anonymous.invalid - as in RFC 3325
> 
> 
> This addresses bug ASTERISK-19465.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 358434 
>   /trunk/channels/sip/include/sip.h 358434 
>   /trunk/configs/sip.conf.sample 358434 
> 
> Diff: https://reviewboard.asterisk.org/r/1803/diff
> 
> 
> Testing
> -------
> 
> I've done some basing test with outgoing calls and everything seems to wroks fine.
> 
> 
> Thanks,
> 
> jamicque
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120307/3ffc9cbc/attachment.htm>