Li Li, Comments inline:
> Takuya, > > Thanks a lot for your emails. Yes. I assume everyone, including > the caller and callee are in the trusted domain, though I don't know if > this makes sense. We may say that a caller or callee can never be trusted:) > I think the assumption will make sense especially if we consider the caller and callee to be just SIP network elements not "real" users. For example, considering MGCP endpoints, MGC is the caller or the callee in a SIP sense. MGC can be trusted and will handle privacy information properly with P-Asserted-Identity and Privacy headers. PSTN GW can also be recognized the caller or the callee in a SIP sense. PSTN can handle privacy information if parameters are properly mapped from/into SIP messages. > To my understanding from the RFC 3325, "Privacy: id" is only used when > sending the INVITE to a untrusted domain, that would make you to remove the > P-Asserted-ID header? > As mentioned above, for example, "Privacy: id" may be mapped into Calling Party number parameter: APRI="presentation restricted" at PSTN GW. I think how to deal Privacy: id at UAS is out of scope of RFC3325, but it can be useful information in a variety of circumstances. Regards, Takuya > Regards, > > Li Li > > > -----Original Message----- > > From: Takuya Sawada [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 12, 2003 8:02 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: Re: [Sip-implementors] RE: [Sip] SIP Privacy draft > > > > > > I assumed that the caller and the calle are outside of the > > trusted domain. > > If caller, callee and everything in between is trusted, as in your > > original mail, then Cullen's answer may be sufficient enough. > > > > Regards, > > Takuya > > > > > Hi, > > > > > > According to RFC3325, as described in section 7, the caller > > > should add "Privacy:id" if it wants caller id privacy service. > > > Of course, I think, service providers can offer the service > > to the caller > > > that is provisioned to be anonymous to the callee by default, > > > or with other means, if no Privacy header is present in the request. > > > > > > P-Preferred-Identity header is irrelevant to privacy > > service, I think. > > > P-Preferred-Identiy header will be removed at the first proxy which > > > authenticates the request and populates P-Asserted-Identity > > header(s), > > > accordingly. > > > > > > From header should be anonymous. According to RFC3261 > > section 8.1.1.3, > > > the displayname should be "Anonymous" and URI should be a > > syntactically > > > correct but meaningless URI like sip:[EMAIL PROTECTED] > > > In RFC3398 section 12.1, there is an example of anonymous From like; > > > From: Anonymous <sip:[EMAIL PROTECTED]>. > > > I think we should use at least invalid TLD which the receiver can > > > safely know it is invalid URI. > > > > > > Proxy will remove P-Asserted-Identiy header(s) if > > Privacy:id is present, > > > when it sends the request to the untrusted party. > > > Then, the caller's identity will not be shown at the callee. > > > We need every SIP entity in between to have trusty relationship, > > > possibly defined Spec(T). > > > > > > Regards, > > > Takuya > > > > > > > Using rfc 3325, if I want to do a feature of "Caller Id > > presentation > > > > restriction", how should I do it, assuming caller, callee > > and everything > > > > in between is trusted? The caller should place a > > P-Preferred-ID in the > > > > INVITE message that has "anonymous" in the display field and also > > > > use "anonymous" in the display field in the "from" header? > > > > > > > > Thanks, > > > > > > > > Li Li > > > > > > > > > > > > > -----Original Message----- > > > > > From: Cullen Jennings [mailto:[EMAIL PROTECTED] > > > > > Sent: Monday, March 10, 2003 11:23 AM > > > > > To: 'Li Li'; [EMAIL PROTECTED] > > > > > Subject: RE: [Sip] SIP Privacy draft > > > > > > > > > > > > > > > > > > > > It became RFC 3325 > > > > > > > > > > http://www.ietf.org/rfc/rfc3325.txt > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > > > > > Behalf Of Li Li > > > > > > Sent: Monday, March 10, 2003 6:39 AM > > > > > > To: '[EMAIL PROTECTED]' > > > > > > Subject: [Sip] SIP Privacy draft > > > > > > > > > > > > > > > > > > Can anybody help me to understand what happened to the > > > > > > privay draft that had the remote-party-ID header? Is > > > > > > it completely obsoleted? Or is it moved to some other > > > > > > draft? RFC 3323 does not include such header operation > > > > > > mechanism. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Li Li > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Burnside, Andrew > > [mailto:[EMAIL PROTECTED] > > > > > > > Sent: Monday, March 10, 2003 8:49 AM > > > > > > > To: '[EMAIL PROTECTED]' > > > > > > > Subject: [Sip] Inter-domain QoS with SIP > > > > > > > > > > > > > > > > > > > > > Hello > > > > > > > > > > > > > > I am currently looking at options for providing QoS managed > > > > > > > inter-domain > > > > > > > connections using SIP. This will probably be in a DiffServ > > > > > > > architecture, > > > > > > > with aggregated flows between domains where possible. Has > > > > > > > there been much > > > > > > > work done in this area with SIP? > > > > > > > > > > > > > > I saw that Henry Sinnreich had an Internet Draft out on this > > > > > > > topic back in > > > > > > > 2000, though I can't find any references to > > subsequent work. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Andrew Burnside > > _______________________________________________ > > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > > This list is for NEW development of the core SIP Protocol > > > > > > > Use [EMAIL PROTECTED] for questions > > on current sip > > > > > > > Use [EMAIL PROTECTED] for new developments on the > > > > > application of sip > > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP Protocol > > > > > > Use [EMAIL PROTECTED] for questions on current > > > > > > sip Use [EMAIL PROTECTED] for new developments on the > > > > > > application of sip > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip-implementors mailing list > > > > [EMAIL PROTECTED] > > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > > > -------- > > > Takuya Sawada > > > KDDI Corporation (KDDI) > > > KDDI Bldg. 2-3-2 Nishishinjuku Shinjuku-ku, > > > Tokyo 163-8003, Japan > > > Tel: +81-3-3347-7406 > > > Fax: +81-3-3347-7418 > > > [EMAIL PROTECTED] > > > _______________________________________________ > > > Sip-implementors mailing list > > > [EMAIL PROTECTED] > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > -------- > > Takuya Sawada > > KDDI Corporation (KDDI) > > KDDI Bldg. 2-3-2 Nishishinjuku Shinjuku-ku, > > Tokyo 163-8003, Japan > > Tel: +81-3-3347-7406 > > Fax: +81-3-3347-7418 > > [EMAIL PROTECTED] > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -------- Takuya Sawada KDDI Corporation (KDDI) KDDI Bldg. 2-3-2 Nishishinjuku Shinjuku-ku, Tokyo 163-8003, Japan Tel: +81-3-3347-7406 Fax: +81-3-3347-7418 [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
