Subject: AW: [Sipping] Screened From: and Privacy

From: "Jesske, R" <[email-masked]>
Date: Wed, 17 Apr 2002 09:54:45 +0200

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Gesendet am: Dienstag, 16. April 2002 16:23
> An: Dean Willis
> Cc: Sipping (E-mail)
> Betreff: Re: [Sipping] Screened From: and Privacy
> 
> Dean Willis writes:
> 
>  > Exactly. But they're going to defin their own Subject 
> field and other
>  > user (not SUBSCRIBER) data. I'm arguing that the display name field
>  > (From:) falls into this category.
> 
> yes they could if there is an easy way to enter a subject field, which
> none of the phones i have seen has.  this is analogous to 
> using someone
> else's email account.  you can set the subject line, but not from whom
> the message came from, i.e., the from field.
> 
>  > Because if the display name field (From:) is part of the SUBSCRIBER
>  > data, as you are arguing, then it falls into 
> network-controlled privacy
>  > management regulation and we end up with "MUST B2BUA 
> everything." If it
>  > is a USER field, then regulation affects it much more lightly.
> 
> i'm arguing that the whole from field belongs to the user whose phone
> i'm borrowing and there is no problem whatsoever with privacy
> regulation.  the privacy what i get is the privacy of the person whose
> phone (or "line") i'm using.  if i borrow someone else's cell phone, i
> don't get my own privacy, but the privacy of the phone owner. 
> if i want
> my own privacy, i need to change the sim.
> 
>  > Life is much better if we consider "From:", along with 
> "Subject:" and
>  > other such fields, as  per-call user-provided data 
> intended for display
>  > to the other end of the dialog. Filtering the From, as you 
> are doing,
>  > forces it into the regulatory realm in a way that you're 
> not going to
>  > like.
> 
> so far we haven't had any other field than the from field to identify
> the calling party:
> 
> 20.20 From The From header field indicates the initiator of the
>    request. This may be different from the initiator of the
>    dialog. Requests sent by the callee to the caller use the callee s
>    address in the From header field. The optional  display-name  is
>    meant to be rendered by a human user interface. A system SHOULD use
>    4280 the display name  Anonymous  if the identity of the 
> client is to
>    remain hidden.
> 
> all sip phones on the market include the calling user's address in the
> from field.  they do not have any other field for that 
> purpose and thus
> i have not had any other way to make sure that the callee address as
> seen by the pstn has not been faked.  if i had not used the from field
> for that purpose, there could not (for regulatory reasons) 
> have been any
> sip to pstn service in finland.

That is the problem for the interworking with PSTN, that the phone include the From header. For the interworking case with the PSTN the From header is a not trusted information (because it is direct from the user and not verified from the network). But if there is a network provided indication (from a trusted network)that verifies that the From is the true user address (like the RPID do this with the screen = yes), than the Interworking entity can map the information in a proper way to the PSTN (including the regulatory aspects are fulfilled).    
There will be no PSTN Operator that take an untrusted From Header to a calling party number --> instead the PSTN operator will set up a new calling party number that is network provided and trusted!
> 
> since there is already lots of sip phones on the market 
> owners of which
> do want to make pstn calls, i have to keep on screening calls based on
> the from field for a very long time to come.  also, many of 
> the proxies
> on the marker can today do this from field screening.  changing it so
> something else would do nothing else but make things more complicated.
> 
> of course operational complexity and backwards compatibility is not a
> problem for vendors like dynamicsoft and nortel, who do not 
> need to run
> sip services.
> 
> -- juha
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

Best Regards 

Roland Jesske

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Wed, 17 Apr 2002 11:15:27 +0300

Jesske, R writes:

 > That is the problem for the interworking with PSTN, that the phone
 > include the From header. For the interworking case with the PSTN the
 > >From header is a not trusted information (because it is direct from
 > the user and not verified from the network). 

in my case it IS verified.

 > But if there is a
 > network provided indication (from a trusted network)that verifies
 > that the From is the true user address (like the RPID do this with
 > the screen = yes), than the Interworking entity can map the
 > information in a proper way to the PSTN (including the regulatory
 > aspects are fulfilled). 

i don't see how rpid would make things any more trusted than the from
field. if two providers don't trust each other, they would not trust
the rpid any more than the from field.

 > There will be no PSTN Operator that take an untrusted From Header to
 > a calling party number --> instead the PSTN operator will set up a
 > new calling party number that is network provided and trusted!

to which number the network would set the calling party number?  my sip
users can have any number of calling party numbers belonging to any
number of calling areas and soon even to any number of countries.  

thus the user thus MUST have some means to indicate to me which of those
numbers that i have allocated to the user, the user wants to use as the
calling party number in a particular call.  today this information is
carried in the uri of the from field, which becomes a trusted entity
after i have checked its validity.  

it is ok for me to add "screen=yes" parameter to the from field although
i don't need that information for anything. and if you want to copy the
from field to another rpid field and have "screen=yes" there, it is ok
with me too as long as i'm not forced to do that myself.

-- juha