RE: [Sipping-tispan] Re: TIP/TIR requirements

["Drage, Keith (Keith)" <[e-mail]>]

It depends what you mean by asserted. Assertion is based on authentication and trust models between different operators.

It case it is not clear from the thread, I believe the number we are talking about is the additional number rather than the one contained in a response in the P-Asserted-Identity header. This number is represented in the PSTN world by the generic number in ISUP, and as the first presented Connected number information element when there are two presented.

The P-Asserted-Identity is only asserted to the extent that it is known to be one owned by a particular user who is making the call. The connected user has been authenticated by the connected user network. If the calling network and the connected user network are diffferent networks, the calling network trusts the connected user network in asserting that users identity. In the existing PSTN/ISDN that trust only occurs if the two networks are public networks, or if the connected user network supplies one of a set of numbers that can be validated by some supporting public network.

For the generic number, in the PSTN/ISDN, a special arrangement is supposed to exist, and while it does not say so, at least in Europe this special arrangement would only be given to operators of enterprise networks or equivalent, which does imply some degree of trust to the supplying enterprise network. It is not given to an end terminal user, and the supplying enterprise network might be expected to authenticate the end user before supplying the number, or rely on its own trust arrangements. While it cannot be policed in the signalling, it is a privilege that can be expected to be taken away if it is abused. The capability is necessary as the enterprise network may be allowed to break into the public network at a remote connect point (for tariff reasons) and the public network has insufficient knowledge to know if the number supplied really belongs to that user.

I understand North America may be more flexible in what it allows, and in contravention of the equivalent ITU-T Recommendations. As such they are therefore untrusted by other network operators.

As such it is not an equivalent of the From header. Neither is it the P-Asserted-Identity, as the trust bestowed on it is less than that which public network operators would desire.

regards

Keith

Keith Drage
Lucent Technologies
[e-mail]
tel: [phone]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Miguel Garcia
> Sent: 07 September 2005 19:21
> To: Michael Hammer (mhammer)
> Cc: [e-mail]; Alexeitsev, D
> Subject: Re: [Sipping-tispan] Re: TIP/TIR requirements
> 
> 
> I am certainly not the expert in supplementary services in 
> the PSTN, but 
>   I have been told that this identity is never asserted by 
> the network, 
> so the callee can put there whatever he wants.
> 
> During the discussions of solutions we looked at headers like 
> Reply-To, 
> and In-Reply-To, but their semantics are well defined and do 
> not match 
> the requirements.
> 
> /Miguel
> 
> Michael Hammer (mhammer) wrote:
> 
> > If this is not an asserted identity, then what good is it?
> > 
> > I thought that the CLIP and COLP were complementary and identical in
> > type.  But, perhaps that is a subtlety I missed.
> > 
> > Mike
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: [e-mail] 
> >>[mailto:[e-mail]] On Behalf Of Miguel Garcia
> >>Sent: Wednesday, September 07, 2005 4:03 AM
> >>To: Schmidt, Christian
> >>Cc: [e-mail]; Alexeitsev, D
> >>Subject: [Sipping-tispan] Re: TIP/TIR requirements
> >>
> >>Inline discussion.
> >>
> >>Schmidt, Christian wrote:
> >>
> >>
> >>>Some comments / questions concerning the TIP/TIR requirements:
> >>>
> >>>- What happens, when the caller is in PSTN and the callee 
> >>
> >>provides a 
> >>
> >>>SIP URI as identity? Will it be translated at the gateway 
> >>
> >>to a E.164 number?
> >>
> >>I don't know what people want to do in this scenario, but in 
> >>my opinion the responsibility lies in the calee, so if the 
> >>callee offers only a SIP URI, and not both a SIP URI and TEL 
> >>URL, then the network shouldn't be doing this type of 
> >>translations. Remember that this is not an asserted identity, 
> >>so this should be end-to-end information
> >>
> >>
> >>>- TIP-1: type error: calle > callee
> >>
> >>Fixed.
> >>
> >>
> >>>- How to handle identity restriction from PSTN/ISDN side? 
> Sould the 
> >>>gateway delete both identity information and restriction 
> >>
> >>information 
> >>
> >>>in this case?
> >>
> >>If we build on the trust model, and if we consider that the 
> >>PSTN Gateway trusts the IMS network, then I would say no, 
> >>delete at the trusted/not-trusted boundary.
> >>
> >>
> >>
> >>>EQ-TIP-4: If identity information and restriction indication is 
> >>>included in a message, the gateway may not transfer the 
> >>
> >>identity information.
> >>
> >>Is this a proposal for a new requirement? What is the actual 
> >>requirement here? This looks like a clarification.
> >>
> >>/Miguel
> >>
> >>>
> >>>Regards,
> >>>Christian
> >>>
> >>
> >>-- 
> >>Miguel A. Garcia           tel:[phone]
> >>sip:[e-mail]
> >>Nokia Research Center      Helsinki, Finland
> >>
> >>
> >>_______________________________________________
> >>Sipping-tispan mailing list
> >>[e-mail]
> >>https://www1.ietf.org/mailman/listinfo/sipping-tispan
> > 
> > 
> 
> -- 
> Miguel A. Garcia           tel:[phone]
> sip:[e-mail]
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan