Evan Borgström wrote:

Changing the From header is not really a good thing to do, instead you should look at implementing the Remote-Party-ID (RPID) headers using the append_rpid_hf() function and if privacy is requested the privacy=full tag should be applied. The auth modules can retrieve the RPID value from a database or radius engine.

I agree although an exception is allowed for "anonymous" users. This is what we currently use for caller ID blocking. My current replace function call replaces the entire from address (display name and URI) with the anonymous string recommended in RFC3323.

Any modern device (UAC, UAS, Gateway, etc) should support the RPID header and should honor the privacy tag.

I was just told by a consultant that RPID has been deprecated by the IETF. I do not have any more information on this move but if true it suggests that this is the wrong approach. Does anyone have any more information about this? Does anyone have any additional suggestions?

Thanks,Steve

-Evan

Steve Blair wrote:

...

Is it possible to change just the display name portion of the from header? I'm trying to implement caller ID blocking but we cannot remove the actual from URI because that breaks our gateway based CDR generation. I'm hoping changing the from header to something like:

from="Anonymous" sip:376826@myschool.edu;tag=003094

Thanks, Steve

---

This e-mail has been scanned by Verizon Managed Email Content Service, using Skeptic™ technology powered by MessageLabs. For more information on Verizon Managed Email Content Service, visit http://www.verizonbusiness.com. ______________________________________________________________________

Just to throw another of my $0.02 in here I'd like to point out that the RFC for PAI states (section 9.1):

A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec. There may be one or two P-Asserted-Identity values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI.

So to correctly identify yourself to the PSTN you need to send two PAI headers, one sip & one tel. For example:

P-Asserted-Identity: "Cullen Jennings" sip:fluffy@cisco.com P-Asserted-Identity: tel:+14085264000

This is hard to accomplish with the current stable version of SER, the version in CVS is another story. And while I encourage forward movement in the protocol the RPID accomplishes transporting of Caller-ID information to calls destined for the PSTN much better IMHO as not all PSTN gateways support the PAI headers and the RPID doesn't need to a "trusted" resource, simply how the call should be identified.

Finally, just because something's depreciated doesn't mean it doesn't do a good job at what it was intended for, look at how many sites still run the 1.3 branch of Apache and they're at 2.2 now. I know it's apples & oranges, but I think I've conveyed my side of the argument...

-Evan

Evan Borgström wrote:

I believe that the consultant is referring to the RFC 3325; P-Asserted-Identity & Privacy headers. The RPID draft was depreciated many moons ago but it's still much more widely supported than any other method of transporting identity and privacy information.

We transport both RPID & PAI as we have one interconnect that only supports the PAI while 90% of the others only support RPID (with the remaining few supporting both).

-Evan

Steve Blair wrote:

...

I was just told by a consultant that RPID has been deprecated by the IETF. I do not have any more information on this move but if true it suggests that this is the wrong approach. Does anyone have any more information about this? Does anyone have any additional suggestions?

Thanks,Steve

---

Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

Jiri Kuthan wrote:

At 22:34 08/08/2006, Steve Blair wrote:

...

Evan Borgström wrote:

...

  Changing the From header is not really a good thing to do, instead you

should look at implementing the Remote-Party-ID (RPID) headers using the append_rpid_hf() function and if privacy is requested the privacy=full tag should be applied. The auth modules can retrieve the RPID value from a database or radius engine.

I agree although an exception is allowed for "anonymous" users. This is what we currently use for caller ID blocking. My current replace function call replaces the entire from address (display name and URI) with the anonymous string recommended in RFC3323.

...

  Any modern device (UAC, UAS, Gateway, etc) should support the RPID

header and should honor the privacy tag.

I was just told by a consultant that RPID has been deprecated by the IETF. I do not have any more information on this move but if true it suggests that this is the wrong approach. Does anyone have any more information about this? Does anyone have any additional suggestions?

RPID is being used in many existing deploments. There is now the Identity header field which made it to RFC and does pretty much the same thing.

In the upcoming SER release, we solve it by downloading the corresponding number from user profile, and leaving it to script to "wrap" the originator's phone number by properly formatted header field.

Please clarify. "...downloading the corresponding number...". From where to where? Do you mean extracting the user portion of the From header URI from the usr_preference table?

-Steve

-jiri

-- Jiri Kuthan http://iptel.org/~jiri/

Jiri Kuthan wrote:

At 23:23 09/08/2006, Steve Blair wrote:

...

Please clarify. "...downloading the corresponding number...". From where to where? Do you mean extracting the user portion of the From header URI from the usr_preference table?

Well, that's the kind of documentation issues which are badly backlogged :-)

with the upcoming SER release, all user information is gathered in user_attrs table. This table includes the caller identity, as well as anything else you may wish to associate with a subscriber (gender, credit-card, etc.) keyed by user's UID.

One of the attributes may then look as this: { uid="24393jf2434-f", name="asserted_id", value="+19199199191" }

I use the usr_preferences table in much the same way today. Flags such as "allow_local" are defined for each subscriber and keyed to the subscriber id. Then I use avps to load and check these flags to determine how to process the "call".

The attribute is called after caller's authentication from the user_attrs table.

Then we use AVP processing to print the AVP using one's favorite header field:

set_attr("rpidheader", "sip:%$asserted_id@%@ruri.host;screen=yes");

I like the ability to use avps in function calls. That should be great.

_Steve

-- the down side is we have not released this new version of SER yet and at the moment I dont dare to give estimates.

-jri

-- Jiri Kuthan http://iptel.org/~jiri/