----- Mensaje original ----- De: ingdavidcespedes@cable.net.co Fecha: Jueves, Diciembre 11, 2008 4:43 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
----- Mensaje original ----- De: Alexandr Dubovikov voip@start4.info Fecha: Viernes, Diciembre 5, 2008 1:13 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
Iñaki Baz Castillo пишет:
El Viernes, 5 de Diciembre de 2008, Juha Heinanen escribió:
if caller needs privacy, then it is up to the UA to send
anonymous from
header together with p-p-i and privacy headers.
I Think this is wrong. The UA should ask for the privacy services, an the proxy must offer this services. This means it must rewrite the information that the UA is willing to keep private with anonymous information, and keep track of it, so it can be replaced when the response is received.
SORRYYYYYYY, you were right. What i'm trying to say is that if the UA insert the p-p-i and privacy headers, the proxy should understand this and do what I say above.
That would be so cool... Unfortunatelly I just know a SIP phone
implementing
it: Twinkle.
Other phones (as Linksys) when the user enables privacy during
a
call, just
set the From Display-Name with "Anonymous" value, while the
From
username
remains the real :(
Yep, some UAC set "Anonymous" only in Display Name. But u can fix it using this code:
$var(url) = $fu; if(is_present_hf("Privacy") && ($hdr(Privacy)=="id" || $hdr(Privacy)=="user") && search("(From|f):\s*"?anonymous")) { uac_replace_from("Anonymous","sip:anonymous@anonymous.invalid"); if(!is_present_hf("P-Asserted-Identity")) { append_hf("P-Asserted-Identity: <$var(url)>\r\n"); }; }
This is what i'm talking about!!!!, but you should check also if the message already have a P-Asserted-Identity that was generated before and remove it.
And how it will know to which transaction it corresponds when the response message comes. It will use the branch id, and the tags? It doesn't matter that some URIs have been replaced with anonymous information? There should be an easier way to do this.
With best regards,
--
Alexandr Dubovikov * baron@iRC RusNet * shurik@start4.info AD1-UANIC * ICQ: 122351182 * http://www.start4.info
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
El Jueves, 11 de Diciembre de 2008, ingdavidcespedes@cable.net.co escribió:
SORRYYYYYYY, you were right. What i'm trying to say is that if the UA insert the p-p-i and privacy headers, the proxy should understand this and do what I say above.
The user sends the request with: From: Anonymous sip:anonymous@XXXXXx P-Preferred-Identity: sip:alice@domain.com Privacy: id
Then the proxy knows who is by checking PPI header and could ask for credentiales. After it, the proxy would remove PPI before routing the request.
If the proxy sends the request to a trusted node, it could add PAI header: P-Asserted-Identity: sip:alice@domain.com Privacy: id
And the next element would remove it if it routes to an untrusted node/endpoint.
Iñaki Baz Castillo wrote:
El Jueves, 11 de Diciembre de 2008, ingdavidcespedes@cable.net.co escribió:
SORRYYYYYYY, you were right. What i'm trying to say is that if the UA insert the p-p-i and privacy headers, the proxy should understand this and do what I say above.
The user sends the request with: From: Anonymous sip:anonymous@XXXXXx P-Preferred-Identity: sip:alice@domain.com Privacy: id
If the user has only one identity, then the PPI header is not necessary as the user's identity will be know by the proxy, and the user for example bill be identified by its authentication username. But this again may cause problem with multidomain configurations and the auth user does not include domain.
Thus, maybe adding the PPI header always is a good idea.
regards klaus
Then the proxy knows who is by checking PPI header and could ask for credentiales. After it, the proxy would remove PPI before routing the request.
If the proxy sends the request to a trusted node, it could add PAI header: P-Asserted-Identity: sip:alice@domain.com Privacy: id
And the next element would remove it if it routes to an untrusted node/endpoint.
El Viernes, 12 de Diciembre de 2008, Klaus Darilion escribió:
The user sends the request with: From: Anonymous sip:anonymous@XXXXXx P-Preferred-Identity: sip:alice@domain.com Privacy: id
If the user has only one identity, then the PPI header is not necessary as the user's identity will be know by the proxy,
Not in case the user wants hidden callerid. In this case the user indicates his identity in PPI and set From to anoymous value, and includes Privacy: id. The proxy then can know who the sender is and can require credentials, and after it removes PPI when sending the request to an untrusted node (or removes PPI and replaces with PAI when sending the request to a trusted node). But PPI is needed in this case even if the user has only one identity.
and the user for example bill be identified by its authentication username.
The proxy can inspect the From header and PPI header to look for a local domain, and just in that case asks for auth (it makes no sense that a proxy requires credentials to an external user).
But this again may cause problem with multidomain configurations and the auth user does not include domain.
That's the point :)
Thus, maybe adding the PPI header always is a good idea.
Unfortunatelly I just know two implementations using PPI when asking for privacy: Twinkle and Sofia stack.
Regards.
Iñaki Baz Castillo wrote:
El Viernes, 12 de Diciembre de 2008, Klaus Darilion escribió:
The user sends the request with: From: Anonymous sip:anonymous@XXXXXx P-Preferred-Identity: sip:alice@domain.com Privacy: id
If the user has only one identity, then the PPI header is not necessary as the user's identity will be know by the proxy,
Not in case the user wants hidden callerid. In this case the user indicates his identity in PPI and set From to anoymous value, and includes Privacy: id. The proxy then can know who the sender is and can require credentials, and after it removes PPI when sending the request to an untrusted node (or removes PPI and replaces with PAI when sending the request to a trusted node). But PPI is needed in this case even if the user has only one identity.
Probably I am being a little academic (or just too tired) but the username in the Authentication header would be enough information for the proxy to add the proper PAI.
regards klaus
and the user for example bill be identified by its authentication username.
The proxy can inspect the From header and PPI header to look for a local domain, and just in that case asks for auth (it makes no sense that a proxy requires credentials to an external user).
But this again may cause problem with multidomain configurations and the auth user does not include domain.
That's the point :)
Thus, maybe adding the PPI header always is a good idea.
Unfortunatelly I just know two implementations using PPI when asking for privacy: Twinkle and Sofia stack.
Regards.
2008/12/12 Klaus Darilion klaus.mailinglists@pernau.at:
Not in case the user wants hidden callerid. In this case the user indicates his identity in PPI and set From to anoymous value, and includes Privacy: id. The proxy then can know who the sender is and can require credentials, and after it removes PPI when sending the request to an untrusted node (or removes PPI and replaces with PAI when sending the request to a trusted node). But PPI is needed in this case even if the user has only one identity.
Probably I am being a little academic (or just too tired) but the username in the Authentication header would be enough information for the proxy to add the proper PAI.
Well, as you already said the username in the Authentication is not enough when handling multidomain. Most probably, the proxy needs to set a realm in the 401/407 and in case of a multidomain environment it depends on the From domain. If From is "anoymous" then PPI header could be inspected to extract the user domain and generates the nonce with the proper realm.
-
ingdavidcespedes＠cable.net.co -
Iñaki Baz Castillo -
Klaus Darilion