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

[Paul Kyzivat <[e-mail]>]

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-sipping-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