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:)
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? 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
