Re: AW: AW: AW: [Sipping-tispan] Requirements 02e

[Paul Kyzivat <[e-mail]>]

Ultimately, what matters is what kind of trust the end user can put in 
what is *displayed* to him. If the display does not include an indicator 
of varying levels of trust, then the user must assume that all displayed 
values have the least trust of all the potential sources of the display.

Then I think there should be specific requirements regarding the trust 
model. Currently the requirements state that there is no trust.

It would seem that existing VoIP deployments that interop with the PSTN 
have already weakened the trust model. Perhaps that needs to be fixed.

	Paul

GARCIN Sebastien RD-CORE-ISS wrote:
> Paul,
> 
> Not excatly. In the PSTN, the callee identity (ISUP generic number "additionnal connected number") is conveyed along with an indication that signals whether the corresponding identity is "user provided, verified and passed" or "network provided".

> I believe that Keith provided a good historical explanation of this requirement (see attached mail). 
> 
> sébastien    
> 
> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part de Paul Kyzivat
> Envoyé : vendredi 30 septembre 2005 15:41
> À : Jesske, R
> Cc : [e-mail]
> Objet : Re: AW: AW: AW: [Sipping-tispan] Requirements 02e
> 
> 
> 
> Jesske, R wrote:
> 
>>Paul,
>>with regard to the interworking to the PSTN/ PSTN Phones via a Terminal adapter the same procedures as used within the PSTN/ISDN apply.
>>
>>The P-Asserted-Id is mapped to the Connected number and the "new P-Additional ID" is mapped to the Generic number (additional Connected number).
>>
>>When at the originating Switch a backward message is received with both elements only the user provided (additional connected number) will presented to the user.
>>The connected number is stored within the exchange.
>>
>>We have the same mapping and procedures with the P-Asserted-ID and the >From header.
> 
> 
> So, what you are telling me is that callerid (and callee identity) is a complete joke - that it has no legitimacy at all! The value displayed
> *may* be a value authenticated by the provider, and it *may* be a value that was provided by the other end without authentication, and I have no way of discerning which it is. So I must assume that callerid is always a lie.
> 
> And this is a service you wish to simulate ???
> 
> 	Paul
> 
> 
>>I hope this clarifies.
>>
>>Bets Regards
>>
>>Roland
>>
>>
>>
>>>-----Ursprüngliche Nachricht-----
>>>Von: Paul Kyzivat [mailto:[e-mail]]
>>>Gesendet: Donnerstag, 29. September 2005 15:05
>>>An: Jesske, Roland
>>>Cc: [e-mail]; [e-mail]
>>>Betreff: Re: AW: AW: [Sipping-tispan] Requirements 02e
>>>
>>>
>>>
>>>
>>>Jesske, R wrote:
>>>
>>>
>>>>Paul,
>>>>The callee has the possibility to subscribe to an not
>>>
>>>screening option so that the additional identity can be included by 
>>>the subscriber.
>>>
>>>
>>>>So the final SIP response will include a P-Asserted-id and
>>>
>>>an additional identity.
>>>
>>>
>>>>So the originating user can receive either two identities
>>>
>>>or only one.
>>>
>>>
>>>>It is up to the UA to decide which one shall be presented.
>>>>
>>>>With regard to the PSTN/ISDN service this is true. But If I
>>>
>>>see the presentation of the From header and the P-Asserted-Identity 
>>>header in forward direction, I think we should do the same in backward 
>>>direction, that both identities will be sent to the Caller back.
>>>
>>>OK. That relieves some of my concern, since you are leaving the 
>>>decision of what to display to the UA, and it is clear to the UA which 
>>>is authenticated and which is not.
>>>
>>>But I am still interested in what you expect to happen when this is 
>>>gatewayed to the PSTN, or when the UA is an analog interface connected 
>>>to a phone with "callerid box". AFAIK, the callerid box will only 
>>>display one name+number per call and doesn't have any way to indicate 
>>>whether the id it is displaying has been authenticated or not. This is 
>>>distressing if the displayed id may sometimes be authenticated and 
>>>sometimes not.
>>>
>>>However I don't find the precedent of From vs P-Asserted-ID as 
>>>compelling for doing something similar in the reverse direction. The  
>>
>>>From and To headers are turning out to be useless in environments that 
>>
>>>use P-Asserted-ID, and probably should just be ignored. In this 
>>>environment it would make some sense to always populate them with 
>>>Anonymous.
>>>
>>>	Paul
>>>
>>>
>>>
>>>>Roland
>>>>
>>>>
>>>>
>>>>
>>>>>-----Ursprüngliche Nachricht-----
>>>>>Von: Paul Kyzivat [mailto:[e-mail]]
>>>>>Gesendet: Montag, 26. September 2005 17:02
>>>>>An: Jesske, Roland
>>>>>Cc: [e-mail]; [e-mail]
>>>>>Betreff: Re: AW: [Sipping-tispan] Requirements 02e
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Jesske, R wrote:
>>>>>
>>>>>
>>>>>
>>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>>Von: [e-mail] 
>>>>>>>[mailto:[e-mail]] Im Auftrag von
>>>
>>>Paul Kyzivat
>>>
>>>
>>>>>>>Gesendet: Donnerstag, 22. September 2005 21:09
>>>>>>>An: Miguel Garcia
>>>>>>>Cc: [e-mail]
>>>>>>>Betreff: Re: [Sipping-tispan] Requirements 02e
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Miguel Garcia wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>That is my understanding. If I recall correctly, the idea
>>>>>>>
>>>>>>>is to emulate
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>the PBX, where the callee can indicate a direct-to-call
>>>>>>>
>>>>>>>number (URI).
>>>>>>>
>>>>>>>OK, so the callee can indicate it. What happens at the calling 
>>>>>>>end? Is it displayed instead of the callerid? Is it displayed in 
>>>>>>>addition to the callerid? Is it retained by the calling UA and 
>>>>>>>used in some circumstance?
>>>>>>
>>>>>>
>>>>>>[RJ] This ID is displayed at the callers UA instead of the
>>>>>
>>>>>dialled number or the P-Asserted-ID sent from the
>>>
>>>terminating network.
>>>
>>>
>>>>>Which network element makes the decision about which one to display? 
>>>>>Is it a network element operating on behalf of the callee, one 
>>>>>operating on behalf of the caller, or is it the caller itself that 
>>>>>decides?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>The Reply-to header can only be used in from the Caller so 
>>>>>
>>>>>it is not possible to use this ID for the callee.
>>>>>
>>>>>
>>>>>
>>>>>>Also the Contact header is not appropriate.
>>>>>>
>>>>>>The equivalent in PSTN is the COLP/COLR service. There we 
>>>>>
>>>>>have a connected and additional connected number. Normally 
>>>>>only the connected number that is a network asserted number 
>>>>>will be shown. But there is also the possibility to allow the 
>>>>>user to present a number sent from his phone directly. (so 
>>>>>called no screening option) So we trust the user that it is a 
>>>>>dialable and valid number. This feature will be used from PBX.
>>>>>
>>>>>
>>>>>
>>>>>>So we want the have the same within SIP. In forward 
>>>>>
>>>>>direction we have the From header and the 
>>>>>P-Asserted-Identity. But in Backward direction the equivalent 
>>>>>to the From header is missing.
>>>>>
>>>>>
>>>>>
>>>>>>So we need such an identity header for the backward 
>>>>>
>>>>>direction setup from the callee.
>>>>>
>>>>>It sounds like the calling device gets one number, which 
>>>>>could be either 
>>>>>a number that the network can vouch for, or one that the network 
>>>>>cannot vouch for. Does the calling device have indication 
>>>
>>>about which 
>>>
>>>
>>>>>case holds? If it doesn't trust the number from the callee, 
>>>>>can it get 
>>>>>the asserted id instead?
>>>>>
>>>>>	Paul
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Roland
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>This sounds a lot like the SIP Reply-To header, which can be 
>>>>>>>there and 
>>>>>>>carry information, but which has never had any clear utility, 
>>>>>>>and so has 
>>>>>>>essentially never been used.
>>>>>>>
>>>>>>>	Paul
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>/Miguel
>>>>>>>>
>>>>>>>>Paul Kyzivat wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Re TIP: What is the caller supposed to do with this 
>>>>>>>
>>>>>>>multiplicity of 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>addresses? Are we to imagine that the device will present 
>>>>>>>
>>>>>>>the caller 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>with all of them so that he may pick which to use when 
>>>>>>>
>>>>>>>making a future 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>call?
>>>>>>>>>
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>>Miguel Garcia wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Inline discussion
>>>>>>>>>>
>>>>>>>>>>Rocky Wang wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Hi, Miguel,
>>>>>>>>>>>
>>>>>>>>>>>For REQ-TIP-1, I agree with you and it is the same of 
>>>>>>>
>>>>>>>ours. But
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>previously I misunderstand it that the direct 
>>>>>>>
>>>>>>>communication means it
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>should reach to the same terminal.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Ok, I can add a clarification that there is not a 
>>>>>>>
>>>>>>>requirement to end 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>up in the same terminal.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>But for REQ-TIP-3, maybe there are still some 
>>>>>>>
>>>>>>>security problem.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>Suppose user B set and his terminal returns a 
>>>>>
>>>>>subscriber C's URI 
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>back to
>>>>>>>>>>>the calling party A, then what will happen? It will be 
>>>>>>>
>>>>>>>possible that 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>the
>>>>>>>>>>>user A will be misleaded to make a call to C but he 
>>>>>>>
>>>>>>>wants to make 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>one to
>>>>>>>>>>>user B actually.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Shame. As I said, there isn't a requirement for the 
>>>>>>>
>>>>>>>network to assert 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>the additional identity. This has been clarified a few 
>>>>>>>
>>>>>>>times in the 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>past, and remember, I am not the owner of the 
>>>>>>>
>>>>>>>requirements, just the 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>scribe. So from TISPAN point of view, the requirement is 
>>>>>>>
>>>>>>>as is, and 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>the security implications are accepted.
>>>>>>>>>>
>>>>>>>>>>/Miguel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Best Regards,
>>>>>>>>>>>Rocky Wang
>>>>>>>>>>>
>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>From: Miguel Garcia [mailto:[e-mail]] Sent: 
>>>>>>>>>>>2005?9?21? 14:37
>>>>>>>>>>>To: Rocky Wang
>>>>>>>>>>>Cc: [e-mail]
>>>>>>>>>>>Subject: Re: [Sipping-tispan] Requirements 02e
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Hi Rocky:
>>>>>>>>>>>
>>>>>>>>>>>inline discussion.
>>>>>>>>>>>
>>>>>>>>>>>Rocky Wang wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>But I have some more doubts on TIP:
>>>>>>>>>>>>REQ-TIP-1: In addition to any network asserted 
>>>>>>>
>>>>>>>identity, it must be
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>          possible for the callee to indicate in a 
>>>>>>>
>>>>>>>SIP response an
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>          additional identity where he is reachable 
>>>>>>>
>>>>>>>for future
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>          direct communications.
>>>>>>>>>>>>Does it mean the back identifier must be something 
>>>>>>>
>>>>>>>like gruu? The 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>one who answers the call from one endpoint does not 
>>>>>>>
>>>>>>>always mean the 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>caller should make a call to this endpoint directly later.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>As far as I understand, there is not a requirement for 
>>>>>>>
>>>>>>>this to be a 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>GRUU. This is just another URI that would lead to the 
>>>>>>>
>>>>>>>same person, 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>but not necessarily to the same terminal.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>REQ-TIP-3: The identity mentioned in REQ-TIP-1 is 
>>>>>>>
>>>>>>>considered an end
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>          user supplied information that is not 
>>>>>>>
>>>>>>>asserted by the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>          network.
>>>>>>>>>>>>Does it mean the network equipments just transfer 
>>>
>>>the called 
>>>
>>>
>>>>>>>>>>>>party's identifier provided by the called party 
>>>>>>>
>>>>>>>endpoint? It must 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>be also asserted, I think. Or, it will cause some 
>>>>>>>
>>>>>>>security problem.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>It means that the network does not verify the validity 
>>>>>>>
>>>>>>>of this URI. 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>It is up to the user to put something meaningful there. 
>>>>>>>
>>>>>>>This is the 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>requirement.
>>>>>>>>>>>
>>>>>>>>>>>BR,
>>>>>>>>>>>
>>>>>>>>>>>     Miguel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>Regards,
>>>>>>>>>>>>Rocky Wang
>>>>>>>>>>>>
>>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>>From: Miguel Garcia [mailto:[e-mail]]
>>>>>>>>>>>>Sent: 2005?9?20? 14:46
>>>>>>>>>>>>To: Rocky Wang
>>>>>>>>>>>>Cc: [e-mail]
>>>>>>>>>>>>Subject: Re: [Sipping-tispan] Requirements 02e
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>Hi Rocky:
>>>>>>>>>>>>
>>>>>>>>>>>>Yes, I think we agreed that this is a missing 
>>>>>>>
>>>>>>>requirement, but we want
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>to write it down when we have finished the other 
>>>>>>>
>>>>>>>requirements, because
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>it may happen that the calling part categories 
>>>>>>>
>>>>>>>requirements help us in
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>creating a proper dependency.
>>>>>>>>>>>>
>>>>>>>>>>>>So this is not forgotten, it will be added at a later time.
>>>>>>>>>>>>
>>>>>>>>>>>>BR,
>>>>>>>>>>>>
>>>>>>>>>>>>  Miguel
>>>>>>>>>>>>
>>>>>>>>>>>>Rocky Wang wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>Hi, Migues,
>>>>>>>>>>>>>As I considered, the requirement of overrding ACR 
>>>>>>>
>>>>>>>service must be
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>there as a formal requirement. Maybe there are some 
>>>>>>>
>>>>>>>ways that the 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>called AS to get enough information to determine that 
>>>>>>>
>>>>>>>it can or 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>cannot
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>override the ACR, but there are some cases the 
>>>>>>>
>>>>>>>simulation service 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>must
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>be overrided, including the case you listed in the 02a 
>>>>>>>
>>>>>>>version. It 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>can
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>be like this: 1. The originating network shall be able 
>>>>>>>
>>>>>>>to take enough
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>calling party's information to the terminating network 
>>>>>>>
>>>>>>>to help to 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>override the callee's ACR service. 2. The 
>>>
>>>terminating network 
>>>
>>>
>>>>>>>>>>>>>shall be
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>able to override the callee's ACR simulation service 
>>>>>>>
>>>>>>>if the caller is
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>authorized to do this based on the caller's information.
>>>>>>>>>>>>>
>>>>>>>>>>>>>Rocky Wang
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>-----Original Message-----
>>>>>>>>>>>>>From: [e-mail]
>>>>>>>>>>>>>[mailto:[e-mail]] On Behalf Of 
>>>>>>>
>>>>>>>Miguel Garcia
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>Sent: 2005?9?9? 20:57
>>>>>>>>>>>>>To: '[e-mail]'
>>>>>>>>>>>>>Subject: [Sipping-tispan] Requirements 02e
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Hi:
>>>>>>>>>>>>>
>>>>>>>>>>>>>I have another working copy of the TISPAN 
>>>>>>>
>>>>>>>requirements, now version
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>02e:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>
>>>>>>>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
>>>>>>>g-tispan 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>-r
>>>>>>>>>>>>>equirements-02e.html
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipp
>>>>
>>>>ing-tispan
>>>>
>>>>
>>>>
>>>>>>>>>>>-r
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>equirements-02e.txt
>>>>>>>>>>>>
>>>>>>>>>>>>And a diff version with respect 02d:
>>>>>>>>>>>>
>>>>>>
>>>>>>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
>>>>>
>>>>>g-tispan 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>-r
>>>>>>>>>>>equirements-02d-to-e.html
>>>>>>>>>>>
>>>>>>>>>>>The main changes this time are:
>>>>>>>>>>>
>>>>>>>>>>>- Rewording of the CCBS/CCNR requirements as per our 
>>>
>>>discussion. I
>>>
>>>
>>>>>>>>>>>have
>>>>>>>>>>>added a few definitions and try to reorder them 
>>>
>>>sequentially, so 
>>>
>>>
>>>>>>>>>>>that they are a bit easier to understand.
>>>>>>>>>>>- Clarification that the TIP requirements are for an 
>>>
>>>additional (to
>>>
>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>asserted) identity.
>>>>>>>>>>>- Addition of the Communication Waiting requirements
>>>>>>>>>>>
>>>>>>>>>>>Please feel free to comment, but bear in mind that due to the 
>>>>>>>>>>>TISPAN meeting next week most of the TISPANers will 
>>>
>>>have limited 
>>>
>>>
>>>>>>>>>>>time to discuss.
>>>>>>>>>>>
>>>>>>>>>>>/Miguel
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>_______________________________________________
>>>>>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
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> RE: [Sipping-tispan] Re: TIP/TIR requirements
> From:
> "Drage, Keith \(Keith\)" <[e-mail]>
> Date:
> Thu, 8 Sep 2005 20:38:54 +0200
> To:
> "Miguel Garcia" <[e-mail]>om>, "Michael Hammer 
> \(mhammer\)" <[e-mail]>
> 
> To:
> "Miguel Garcia" <[e-mail]>om>, "Michael Hammer 
> \(mhammer\)" <[e-mail]>
> CC:
> <[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

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