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

[Justin <[e-mail]>]

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
> 

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