Hi, "Remote-Party-ID" is a draft ("draft-ietf-sip-privacy-04") [1] expired in 2002 while "P-Asserted-Identity" is a official RFC (3325) [2].
I'd like to know why OpenSer manages RPID in some functions ("auth" module) instead of PAI. I assume that some gateways just implement RPID and so, but can't understand why PAI is ignored (the use of PAI is extended in gateways).
As a curiosity, both draft and RFC have really **common** parts, as chapter "Introduction" (4 in draft, 3 in RFC):
"3/4 Introduction
Various providers offering a telephony service over IP networks have selected SIP as a call establishment protocol. Their environments require a way for trusted network elements operated by the service providers (for example SIP proxy servers) to communicate the identity of the subscribers to such a service, yet also need to withhold this information from entities that are not trusted when necessary. Such networks typically assume some level of transitive trust amongst providers and the devices they operate.
These networks need to support certain traditional telephony services and meet basic regulatory and public safety requirements. These include Calling Identity Delivery services, Calling Identity Delivery Blocking, and the ability to trace the originator of a call ... "
So my question is again:why OpenSer supports RPID related functions and not PAI functions?
Thanks for any explanation.
[1] RPID: http://tools.ietf.org/html/draft-ietf-sip-privacy-04 [2] PAI: http://www.faqs.org/rfcs/rfc3325.html
RPID died and was replaced by PAI, but not until after thousands of implementations of UA made RPID common. Eventually it may go away....
On Jan 20, 2008, at 3:20 AM, Iñaki Baz Castillo ibc@aliax.net wrote:
Hi, "Remote-Party-ID" is a draft ("draft-ietf-sip-privacy-04") [1] expired in 2002 while "P-Asserted-Identity" is a official RFC (3325) [2].
I'd like to know why OpenSer manages RPID in some functions ("auth" module) instead of PAI. I assume that some gateways just implement RPID and so, but can't understand why PAI is ignored (the use of PAI is extended in gateways).
As a curiosity, both draft and RFC have really **common** parts, as chapter "Introduction" (4 in draft, 3 in RFC):
"3/4 Introduction
Various providers offering a telephony service over IP networks have selected SIP as a call establishment protocol. Their environments require a way for trusted network elements operated by the service providers (for example SIP proxy servers) to communicate the identity of the subscribers to such a service, yet also need to withhold this information from entities that are not trusted when necessary. Such networks typically assume some level of transitive trust amongst providers and the devices they operate.
These networks need to support certain traditional telephony services and meet basic regulatory and public safety requirements. These include Calling Identity Delivery services, Calling Identity Delivery Blocking, and the ability to trace the originator of a call ... "
So my question is again:why OpenSer supports RPID related functions and not PAI functions?
Thanks for any explanation.
[1] RPID: http://tools.ietf.org/html/draft-ietf-sip-privacy-04 [2] PAI: http://www.faqs.org/rfcs/rfc3325.html
-- Iñaki Baz Castillo
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Iñaki Baz Castillo wrote:
Hi, "Remote-Party-ID" is a draft ("draft-ietf-sip-privacy-04") [1] expired in 2002 while "P-Asserted-Identity" is a official RFC (3325) [2].
I'd like to know why OpenSer manages RPID in some functions ("auth" module) instead of PAI. I assume that some gateways just implement RPID and so, but can't understand why PAI is ignored (the use of PAI is extended in gateways).
RPID was never an RFC, but it was implemented by Cisco and all of the Cisco stuff out there support it. PAI is supported only by newer Cisco stuff. Thus, most gateways support RPID too to be compatible with Cisco.
When ser implemented RPID support, there was not PAI defined. Thus, RPID support was first and it was implemented into auth module - and more or less hardcoded.
Later, ser/openser become more flexible (pseudo variables, AVPs ...) and you could load AVPs from DB and add a new header with the AVP. Thus, for adding a header with values read from database there was no reason anymore to implement a certain add_pai_hf function as you could do everything with append_hf and AVPs.
regards klaus
As a curiosity, both draft and RFC have really **common** parts, as chapter "Introduction" (4 in draft, 3 in RFC):
"3/4 Introduction
Various providers offering a telephony service over IP networks have selected SIP as a call establishment protocol. Their environments require a way for trusted network elements operated by the service providers (for example SIP proxy servers) to communicate the identity of the subscribers to such a service, yet also need to withhold this information from entities that are not trusted when necessary. Such networks typically assume some level of transitive trust amongst providers and the devices they operate.
These networks need to support certain traditional telephony services and meet basic regulatory and public safety requirements. These include Calling Identity Delivery services, Calling Identity Delivery Blocking, and the ability to trace the originator of a call ... "
So my question is again:why OpenSer supports RPID related functions and not PAI functions?
Thanks for any explanation.
[1] RPID: http://tools.ietf.org/html/draft-ietf-sip-privacy-04 [2] PAI: http://www.faqs.org/rfcs/rfc3325.html
El Lunes, 21 de Enero de 2008, Klaus Darilion escribió:
Iñaki Baz Castillo wrote:
Hi, "Remote-Party-ID" is a draft ("draft-ietf-sip-privacy-04") [1] expired in 2002 while "P-Asserted-Identity" is a official RFC (3325) [2].
I'd like to know why OpenSer manages RPID in some functions ("auth" module) instead of PAI. I assume that some gateways just implement RPID and so, but can't understand why PAI is ignored (the use of PAI is extended in gateways).
RPID was never an RFC, but it was implemented by Cisco and all of the Cisco stuff out there support it.
PAI is supported only by newer Cisco stuff.
I can confirm that Nortel CS2000 allows both RPID and PAI. ;)
Later, ser/openser become more flexible (pseudo variables, AVPs ...) and you could load AVPs from DB and add a new header with the AVP. Thus, for adding a header with values read from database there was no reason anymore to implement a certain add_pai_hf function as you could do everything with append_hf and AVPs.
Yes, that makes sense. Thanks for the explanation.
-
Alan Crosswell -
Iñaki Baz Castillo -
Klaus Darilion