Re: [Sipping-tispan] Question on the AoC Requirements

[Miguel Garcia <[e-mail]>]

Justin:

You can find the requirement in the TISPAN document 03030, Section 
4.2.1. The reference to ETS 300 180 is added there as well.

/Miguel

zhouqing wrote:

> Hi, all,
> 
> It's is mentioned in the draft of the sipping-tispan requirements:
>    The Advice of Charge service allows the caller to request the
>    displaying of tariff information related to the communication.  The
>    caller can request the displaying of charging information at setup
>    time (AoC-S), during a session (AoC-D), or at the end of it (AoC-E),
>    including a few seconds after the communication has ended.
> 
> I have a doubt on the last sentence, "including a few seconds after the 
> communication has ended", it is not present in WI01002 and WI03030, 
> can someone tell me where this requirement come from?
> Thank you!
> 
> ZhouQing(Justin)
> 
> ----- Original Message ----- 
> From: "Paul Kyzivat" <[e-mail]>
> To: "Miguel Garcia" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, September 21, 2005 9:39 PM
> Subject: Re: [Sipping-tispan] Requirements 02e
> 
> 
> 
>>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-sipping-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-sipping-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
> 

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