[Spce-user] Suggested Patch: UPN/NPN with Peer Masking

[Andreas Granig]

Hi Skyler,

On 06/22/2012 01:48 PM, Skyler wrote:
>  Here is a patch I've been using for a few months now. It handles User
> provided display name (caller-id name) and also hides peers from
> subscribers and other peers. 

Thanks for the patch. This is however subject to change for upcoming 2.6.

What we did in trunk as preparation was implementing "enum" preferences,
so in the DB there are predefined values for certain preferences, which
can be selected in a drop-down.

What we're going to introduce on top are preferences like this (still a
draft and might change in the actual implementation):

inbound_upn (peer/dom/usr): {from_displayname, from_username,
ppi_username, pai_username, rpid_username}
inbound_npn (peer): {from_displayname, from_username, ppi_username,
pai_username}

This will control for inbound calls where to take npn (only peer) and
upn from, instead of scanning various SIP headers until something is
found. We might still do a fallback e.g. if you define to take the upn
from display-name, but there is none set.

Then for outbound calls we're going to have preferences like this:

outbound_from_displayname: {none, upn, npn, inbound_displayname}
outbound_from: {upn, npn, subscriber_name}
outbound_ppi: {none, upn, npn, subscriber_name}
outbound_pai: {none, upn, npn, subscriber_name}
outbound_clir: {privacy, anon_from_displayname, anon_from_username}

Using this approach, you can define per user, domain and peer where to
put what dynamically, because peering providers require different values
to be put in different headers (pai vs. ppi for upn/npn and vice versa,
or from/pai for upn/npn etc), and also some end devices expect their
values in different header(-fields).

Andreas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20120622/83113874/attachment.asc>