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

[Miguel Garcia <[e-mail]>]

Hi Justin:

I see your point. If my memory serves, during the IETF meeting in Paris,
there was a question from the audience related to the period of time
where a user can request this type of information. Also there were
questions about the frequency of the information.

I think Denis answered that the user can request the AoC information
evena  few seconds after the session has completed, but perhaps Denis
can answer if remembers better than me. Or perhaps other folks can
comment on this topic as well.

Regards,

       Miguel


Justin wrote:

> Hi, Miguel,
> 
> Thanks for your information.
> 
> Yes, the requirement for ETS 300 180 AOC-E is already there.
> 
> But there is no definition in ETS 300 180 that AOC-E service include 
> the requirement to provide the charging information a few seconds after 
> the communication has ended. 
> 
> As describered in ETS 300 180, the AOC-E service provides the served
> uesr with charging information for a call when the call is terminated.
> 
> So i think it may be a new requirement from AOC-E, is it correct? 
> 
> Justin
> 
> 
> ----- Original Message ----- 
> From: "Miguel Garcia" <[e-mail]>
> Sent: Thursday, September 22, 2005 7:28 PM
> Subject: Re: [Sipping-tispan] Question on the AoC Requirements
> 
> 
> 
>>To: zhouqing <[e-mail]>om>,
>> "'[e-mail]'" <[e-mail]>
>>Message-id: <[e-mail]>
>>MIME-version: 1.0
>>Content-type: text/plain; format=flowed; charset=us-ascii
>>Content-transfer-encoding: 7bit
>>X-Accept-Language: en-us, en, es-es
>>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
>> Gecko/20040804 Netscape/7.2 (ax)
>>References: <000001c5be7e$3326ba60$[e-mail]>
>> <[e-mail]> <[e-mail]>
>> <014101c5bf54$b23fa240$[e-mail]>
>>X-OriginalArrivalTime: 22 Sep 2005 11:28:31.0509 (UTC)
>> FILETIME=[C2C48450:01C5BF68]
>>
>>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
>>

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