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

[Paul Kyzivat <[e-mail]>]

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