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

[jamicque]

> On March 7, 2012, 2:12 p.m., Mark Michelson wrote:
> > /branches/1.8/channels/chan_sip.c, lines 11957-11960
> > <https://reviewboard.asterisk.org/r/1803/diff/2/?file=25877#file25877line11957>
> >
> >     This change seems suspicious to me.
> >     
> >     The comment mentions "fromname" but the if statement checks if p->fromuser is set.
> >     
> >     Why does RPID have to be enabled for you to change d to p->fromdomain?
> >     
> >     As far as I can tell, the domain in the From header is not used for authentication at all. In fact, nothing in the From header is used for authentication. The user portion of the From header can be used for user matching but that's not the same thing as authentication.
> >     
> >     Can you explain this change further?
> >     
> >     Also, the red blob here indicates some trailing whitespace. Get rid of it.

there should be fromuser, not fromname.
I've met many times especially for carriers in Europe peers created on Broadsoft should always send in FROM the name of the peer and domain. That is why I've left it. The CPN is send or in rpid or PAI.

creating such check makes it possible to accomplish such scenario.

If you do not send such information in FROM the call will be rejected.
IMHO it should stay, should I change it?


- jamicque


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


On March 7, 2012, 10:15 a.m., jamicque wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1803/
> -----------------------------------------------------------
> 
> (Updated March 7, 2012, 10:15 a.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 changed to anonymous at anonymous.invalid and rpid header is srtiped.
>     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 and pai header is srtiped. - as in RFC 3325
> 
> When we are using PAI or RPID ,fromname is defined and CLIR, we do not set anonymous at anonymous.invalid - coz this from in this situation is usually used for authentication.
> 
> 
> This addresses bug ASTERISK-19465.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19465
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 358481 
>   /branches/1.8/channels/sip/include/sip.h 358481 
>   /branches/1.8/configs/sip.conf.sample 358481 
> 
> 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/f8d1f0bd/attachment.htm>