[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments
> I would like to understand how one can interpret these texts to mean
> that P-A-ID is a billing identity while From is the user's identity.
The P-A-ID is per definition within 3GPP the public user identity. So also user identity.
Why public Identity, because it was verified by an public (operator) entity.
So the user can be reached by this P-A-ID. So it is the identity of the user sending the message, but it was included by the network.
For what should we use such an asserted identity?
Of course presenting the identity to an destination user is one use.
And since the Identity is trusted of course it is ideal to write Call Data Records. For Billing and accounting purposes. If I not use the P-A-ID what should I use for that? And as far as I know that was also discussed when the P-A-ID was defined.
As far as I know IETF is defining protocol tools that are used in a generic manner and that are not bind to specific uses. So P-A-ID is used in such an generic manner for:
Originating Identification Presentation, Billing, Call Barring services, as criteria for allowing services ect.
Also in RFC4474 is mentioned:
RFC 3325 [12] defines the "id" priv-value token, which is specific to
the P-Asserted-Identity header. The sort of assertion provided by
the P-Asserted-Identity header is very different from the Identity
header presented in this document. It contains additional
information about the sender of a message that may go beyond what
appears in the From header field; P-Asserted-Identity holds a
definitive identity for the sender that is somehow known to a closed
network of intermediaries that presumably the network will use this
identity for billing or security purposes.
...
So it is here also mentioned for what purposes the P-A-ID is used for. And many people looked over this wording as far as I know. How came this people to this assumption?
>From header in the past was a user provided header and therefore not useful for billing at least. But back to the issue.
The From header is a user provided identity (because put in by the sending UA) that is also reflecting the identity where the request is coming from.
The user could set every identity in where he is reachable with his device. So if he has 10 devices at home so he had a couple of addresses possible. Of course such identities could be also used as public identities if configures by the asserting entity. But within some domains(like the IMS) this could lead to more complexity than needed. So this other identities will be handled as private identities that can be set by the user and in addition the P-A-ID will be set as a public one. With all the advantages as mentioned above.
Such a behaviour is also used within the PSTN/ISDN for entities called PBX. With equal principles one asserted identity where you can reach at least the device sending the initial request. And a private identity reaching a special extension.
This principles were discussed also several times on different IETF lists. Based on this assumptions the interworking with the PSTN/ISDN was defined and also services within the IMS.
Based on this I was pointing to these facts that should be taken into consideration within your draft. So at least coping information from a FROM header into the P-A-ID without looking into the P-A-ID and the existing trust relationship of the sending domain. Ideally or at least in many cases the content of the From header would be equal to the content of the P-A-ID. And of course the P-A-ID can be deleted if received from a untrusted domain.
What I'm assuming that your document should show is a possibility to generate a P-A-ID in case the calls enter a trusted domain where a the P-A-ID is needed and not included within the Request and the From is authenticated due to the rules of RFC4474. And vice versa if possible.
Best Regards
Roland
> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:jdrosen at cisco.com]
> Gesendet: Mittwoch, 18. Oktober 2006 16:28
> An: Jesske, Roland
> Cc: sip at ietf.org; Jacobsohn, Dieter; Seibel, Matthias
> Betreff: Re:
> [Sip]draft-rosenberg-sip-identity-coexistence-00.txt further comments
>
>
> Well, this harkens back to my rant during the last IETF meeting. My
> point was that this usage of both P-A-ID and From you are
> describing is
> not the semantics implied by RFC 3325 or RFC 3261, but rather a
> "decision" by 3gpp, ITU and others to use PAID as a billing identity.
>
> Indeed I quote RFC 3325:
>
> 9.1 The P-Asserted-Identity Header
>
> The P-Asserted-Identity header field is used among trusted SIP
> entities (typically intermediaries) to carry the identity
> of the user
> sending a SIP message as it was verified by authentication.
>
>
> To me, the "identity of the user sending a SIP message" is NOT the
> "identity of the entity that will be billed for this
> request". It means
> as it says - it is the identity of the *user* that *sent* the request.
>
> Quoting from RFC 3261:
>
> 8.1.1.3 From
>
> The From header field indicates the logical identity of
> the initiator
> of the request, possibly the user's address-of-record.
>
>
> These are identical definitions, the only difference being the term
> 'logical', which is implied I think in any system that assigns
> identities to users.
>
> I would like to understand how one can interpret these texts to mean
> that P-A-ID is a billing identity while From is the user's identity.
>
> -Jonathan R.
>
>
> Jesske, R wrote:
>
> > Dear all,
> > With regard to the following section I have some concerns
> regarding the
> > thought use of the P-Asserted-Identity.
> >
> > 4.3. Ingress Proxy
> >
> > .... If the identity
> > is verified, the ingress proxy SHOULD insert a
> P-Asserted-ID header
> > field containing the identity contained in the From
> header field of
> > the request. The proxy SHOULD NOT remove the Identity
> and Identity-
> > Info header fields. This allows for SIP networks where there are
> > more than two administrative domains in a request path, and also
> > allows for a UA to verify the signature on its own if it should
> > desire....
> >
> > This will violate the use of the From and P-Asserted-Identity header
> > within the 3GPP IMS, TISPAN IMS and also ITU-T NGN
> including the mapping
> > with the PSTN.
> >
> > The P-Asserted-Identity is used as a public ID that is
> trusted. The From
> > header is set by the user itself and is untrusted. So that
> there is the
> > possibility to have two different identities within one INVITE.
> > To equalise such identities within a B2BUA at the ingress
> even if the
> >>From is also a now secure and trusted ID.
> >
> > Within the NGN this two identities are used for PBX
> services to present
> > the main PBX number and a individual extension of the PBX.
> >
> > Also the deletion and re-inclusion is against the rules of
> the RFC3325.
> > The destination domain is not allowed to change the identity of the
> > originating domain.
> >
> > If such procedures will be done also charging and billing mechanisms
> > used between domains will be violated. because the
> P-Asserted-Identity
> > is the base identity of the origin domain on Billing and charging.
> >
> > Best Regards
> >
> > Roland
> >
>
> --
> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> Cisco Fellow Parsippany, NJ
> 07054-2711
> Cisco Systems
> jdrosen at cisco.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.cisco.com
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip