8 Aug
2006
8 Aug
'06
3:37 p.m.
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
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@net.isc.upenn.edu
8 Aug
8 Aug
4:09 p.m.
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.
Any modern device (UAC, UAS, Gateway, etc) should support the RPID
header and should honor the privacy tag.
-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
5:34 p.m.
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.
______________________________________________________________________
6:37 p.m.
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
7 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 
9 Aug
9 Aug
5:13 p.m.
At 22:34 08/08/2006, Steve Blair wrote:
Evan Borgström wrote:
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.
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
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?
6:23 p.m.
Jiri Kuthan wrote:
At 22:34 08/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?
-Steve
Evan Borgström wrote:
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.
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?
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
6:41 p.m.
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" }
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");
--
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/
10 Aug
10 Aug
10:53 a.m.
Jiri Kuthan wrote:
At 23:23 09/08/2006, Steve Blair wrote:
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".
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" }
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/
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@net.isc.upenn.edu
6614
days inactive
6616
days old
8 comments
3 participants
participants (3)
-
Evan Borgström -
Jiri Kuthan -
Steve Blair