Re: [Sipping-tispan] Advice of Charge (AoC)

[Miguel Garcia <[e-mail]>]

Not to my knowledge (at least with SiP), that is the main reason why we 
are discussing it in this list.

/Miguel

Avasarala Ranjit-A20990 wrote:
> Hi
>    is there any standard or internet draft on advice of charge notification? 
> 
> 
> Regards 
> Ranjit 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Hans Erik van Elburg (RY/ETM)
> Sent: Thursday, February 02, 2006 3:17 PM
> To: Drage, Keith (Keith); Martinez-Rebordosa, Anna; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
> 
> Keith,
> 
> In ISDN if the signalling is not working between the switch and the UE no AoC-D information nor AOC-E information can be delivered.
> 
> It is not required to deliver AOC-E information if the session is cleared by the P-CSCF or any other border node. And certainly not AOC-D information. 
> 
> The advice of charge service does not offer any guarantee that the information is complete or correct always, hence the name Advice of charge.
> 
> Best Regards,
> 
> /Hans Erik
> 
> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[e-mail]]
> Sent: Wednesday, February 01, 2006 5:46 PM
> To: Martinez-Rebordosa, Anna; Hans Erik van Elburg (RY/ETM); [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
> 
> One thing I have missed in this discussion is the essential difference in the architecture between ISDN and IMS provision of this capability.
> 
> In ISDN it is the entity directly communicating with the terminal (i.e. the local exchange) that is providing this functionality.
> 
> In IMS it is intended that this capability is provided by a AS acting either as a proxy or a B2BUA which is at least two proxies deep into the network equipment. Both those intervening proxies have the ability to clear the session under fairly normal conditions, the P-CSCF when it loses the bearer and the S-CSCF when the registration is cleared. At least in the former case (P-CSCF clearing) I would regard it as still part of the service to provide the charge (AOC-D and AOC-E) in that case.
> 
> regards
> 
> Keith
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]]On Behalf Of 
>> Martinez-Rebordosa, Anna
>> Sent: 31 January 2006 13:58
>> To: [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail];
>> [e-mail]
>> Cc: [e-mail]
>> Subject: AW: [Sipping-tispan] Advice of Charge (AoC)
>>
>>
>>
>> John,
>>
>> Totally agree with Hans Erik about the trusted AOC information. 
>>
>> Your other question about session-related charging information. Yes, I 
>> pressume that the charging information to be provided to the served 
>> user applies only to the session been stablished. The invocation of 
>> AoC service is also done at the session stablishment.
>>
>> For better understanding on AoC here some definitions from the ETS 300
>> 182-1:
>>
>> Three AOC supplementary services exist:
>> a)	Charging information at call set-up time (AOC-S)
>>
>> 	When the AOC-S supplementary service is activated, the network shall 
>> provide the user with information about the charging rates at call 
>> establishment. In addition, the network shall inform the served user 
>> if a change in charging rates takes place during the call.
>> The network shall provide the charging information during call 
>> establishment or at the latest at call connection. When there is a 
>> change in the charging rate during the call, the network shall send 
>> information about the new charging rate to the served user
>>
>> b)	Charging information during the call (AOC-D)
>> When the AOC-D supplementary service is activated, the network shall 
>> provide the user with charging information for a call during the 
>> active phase of a call. The network shall provide the charging 
>> information and transfer it to the served user in an appropriate 
>> message. The supplied charging information shall be provided as a 
>> cumulative charge incurred so far for the call (i.e. charges recorded 
>> from the start of the call and until the moment the charging 
>> information is sent to the served user).
>> When the call is released, the network shall send the recorded charges 
>> for the call to the served user in one of the call control messages 
>> clearing the call.
>> If the network has determined that the call is free of charge, then 
>> the network shall send a free-of-charge indication in the first 
>> subsequent message sent to the served user. The network shall not send 
>> any further charging information during the call. When the call is 
>> released, the network shall send the charged amount (zero) in a call 
>> control message clearing the call.
>>
>> c)	Charging information at the end of the call (AOC-E)
>>
>> 	When the AOC-E supplementary service is activated, the network shall 
>> provide the served user with charging information indicating the 
>> recorded charges for a call when the call is released. The network 
>> shall send the charging information to the served user in one of the 
>> call control messages clearing the call.
>>
>>
>>
>> I hope that can clarify some questions.
>> BR,
>> Anna
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Hans Erik van Elburg (RY/ETM)
>> [mailto:[e-mail]]
>> Gesendet: Dienstag, 31. Januar 2006 14:46
>> An: Elwell, John; Martinez Rebordosa, Anna; [e-mail]; 
>> [e-mail];
>> [e-mail]
>> Cc: [e-mail]
>> Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)
>>
>>
>> AOC information header is inserted by an AS in the trust 
>> domain. Further it does not reveal any identity information, 
>> only tariff informatrion that is applicable for the receiving 
>> user. It is the AS of the served user that inserts this 
>> information for the served users UE or access gateway to 
>> render to the user and for bookkeeping purposes.
>>
>> False information received from untrusted networks should 
>> either be removed or rejected at the border of the trust domain.
>>
>> This is the same kind of trust relations that are used to 
>> know that for example P-Asserted-Identity is authenticated by 
>> the network and by nobody else.
>>
>> /Hans Erik
>>
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Elwell, John
>> Sent: Tuesday, January 31, 2006 1:55 PM
>> To: Martinez-Rebordosa, Anna; [e-mail]; 
>> [e-mail]; [e-mail]
>> Cc: [e-mail]
>> Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
>>
>> Anna,
>>
>> Thanks, so the middle option (AOC-D) would tend to steer us 
>> in the direction of SUBSCRIBE/NOTIFY rather than HTTP GET, 
>> because there can be multiple notifications.
>>
>> These three types of AOC are all session-related, yet there 
>> was some recent discussion about AOC applied to other SIP 
>> messaging, not just session-related. Can we assume that AOC 
>> is indeed limited to session-related charges?
>>
>> Some postings to this list have been discussing sending the 
>> charge information in the context of the INVITE-initiated 
>> dialog for the session.
>> An intermediary would insert the charge information, and this 
>> then gives rise to questions about security. What are the 
>> authentication requirements for the charge information? 
>> Depending on requirements, insertion of this information by a 
>> proxy may be problematic. A proxy can't insert a body. It can 
>> insert a header, of course, but that header would not be 
>> covered by the integrity protection that the Identity header 
>> provides. SUBSCRIBE/NOTIFY can draw upon standard security 
>> measures much more easily than in-dialog information.
>>
>> John
>>
>>> -----Original Message-----
>>> From: Martinez-Rebordosa, Anna
>>> [mailto:[e-mail]]
>>> Sent: 31 January 2006 09:25
>>> To: Elwell, John; [e-mail];
>>> [e-mail]; [e-mail]
>>> Cc: [e-mail]
>>> Subject: AW: [Sipping-tispan] Advice of Charge (AoC)
>>>
>>> John,
>>> Aoc is defined on three types: 
>>> - AOC-S: served user received the information at the time of 
>>> establischment the session.
>>> - AOC-D: served user received the information during the session. 
>>> Every t seconds. t is a network operator option.
>>> -AOC-E: served user received the information at the end of the 
>>> session.
>>>
>>> I hope this clarifies a little bit more.
>>>
>>> Anna
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Elwell, John [mailto:[e-mail]]
>>> Gesendet: Montag, 30. Januar 2006 22:29
>>> An: Michael Hammer (mhammer); GARCIN Sebastien RD-CORE-ISS; Miguel 
>>> Garcia
>>> Cc: [e-mail]
>>> Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)
>>>
>>>
>>> Michael,
>>>
>>> It seems to me that HTTP/GET would be a good choice if a single 
>>> immediate response can be expected. SUBSCRIBE/NOTIFY has some clear 
>>> benefits if there is likely to be a delay before the information is 
>>> available (so the subscriber will receive a 2xx response 
>> and await a 
>>> NOTIFY
>>> request) or if the
>>> information might need to be updated during the subscription period 
>>> (multiple NOTIFY requests). Can TISPAN people please 
>> clarify what is 
>>> required?
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: Michael Hammer (mhammer) [mailto:[e-mail]]
>>>> Sent: 30 January 2006 14:58
>>>> To: GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
>>>> Cc: [e-mail]
>>>> Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
>>>>
>>>> All,
>>>>
>>>> A comment from the peanut gallery.
>>>>
>>>> I am concerned that precedents from a single media type service 
>>>> might unduly constrain a solution that uses multiple media types 
>>>> simultaneously, some of which could be session-oriented, some of 
>>>> which might be "connectionless".
>>>> All this talk of piggy-backing and use of 183 does not seem to be 
>>>> generally useful in all situations.
>>>>
>>>> I would suggest that a solution that is general to all types of 
>>>> services and attempts to be as decoupled as possible from those 
>>>> services would minimize the possibility of feature interactions 
>>>> between AoC and other features/services.
>>>>
>>>> That said, the essence of AoC is a request for information that 
>>>> seems to be a natural fit for a Subscribe/Notify type of 
>> operation 
>>>> for request and delivery.  A particular dialog or message will 
>>>> likely need to have an associated address from which this 
>>>> information can be requested.  One or more 
>> values/addresses can be 
>>>> added to message/INVITE to enable a UA to know where to send the 
>>>> Subscribe.  The accounting element will need to be able 
>> to identify 
>>>> the dialog or message and bind that to the charge or charge rate, 
>>>> which seems to be the nature of an Event package.
>>>>
>>>> I suspect that AoC will not be the last type of "Event" 
>> that will be 
>>>> needed for SIP.  Leveraging a general mechanism would be 
>> better than 
>>>> reinventing event reporting for each of N "features" that will 
>>>> arise.  Talk of performance needs to keep a broad 
>> perspective on the 
>>>> overall system.
>>>>
>>>> Mike
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail] 
>>>>> [mailto:[e-mail]] On Behalf Of GARCIN 
>>>>> Sebastien RD-CORE-ISS
>>>>> Sent: Monday, January 30, 2006 8:56 AM
>>>>> To: Miguel Garcia
>>>>> Cc: [e-mail]
>>>>> Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
>>>>>
>>>>> Miguel,
>>>>>
>>>>> Please see answers below [SG]
>>>>>
>>>>> Regards,
>>>>> sebastien
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : Miguel Garcia [mailto:[e-mail]]
>>>>> Envoyé : lundi 30 janvier 2006 12:30 À : GARCIN Sebastien 
>>>>> RD-CORE-ISS Cc : [e-mail] Objet : Re: 
>>>>> [Sipping-tispan] Advice of Charge (AoC)
>>>>>
>>>>> Inline discussion.
>>>>>
>>>>> GARCIN Sebastien RD-CORE-ISS wrote:
>>>>>> Miguel,
>>>>>>
>>>>>> First it may be true that there has been some discussion in
>>>>> the past about this but I think it is still interesting to list 
>>>>> the conclusions of those discussions in order for readers 
>>>>> (including me) to understand if there was indeed a real problem 
>>>>> with piggy-backing solution. Please note the solution is not 
>>>>> exaclty "piggy-backing" because in some flows (e.g. 
>> AoC-S service) 
>>>>> the AS generates the 183 answer and does not wait for a 
>> 183 answer 
>>>>> from the terminating side (see figure 1/ WI3030).
>>>>>> Looking at your points: 
>>>>>>  
>>>>>> 1/ IMS Charging problem and creating artificial SIP message
>>>>>> ------------------------------------------------------------
>>>>>> I am not sure to undertand the problem. The AS is perfectly
>>>>> entitled to create and send 183 answers downstream, 
>> such message 
>>>>> is needed anyway for the service and this has nothing 
>> to do with 
>>>>> "preconditions or sending charging information".
>>>>> Could you please clarify ?
>>>>>
>>>>> So here we go... the AS need to create artificial 183 messages 
>>>>> when there might not be a need to send 183 at all.
>>>>> Think for example that you call someone who happens to be an 
>>>>> automata, such as an answering machine, you will get 200 OK 
>>>>> immediately. This does not require a 183, but you need 
>> to create 
>>>>> it artificially and delay the session just for sending the AoC 
>>>>> information. It would be more natural to create a 
>> separate side-by 
>>>>> dialog for sending the required information.
>>>>>
>>>>> [SG: Why is 183 more artificial than MESSAGE / INFO / 
>> or anything 
>>>>> else ? The 183 does not delay the session in my view since it 
>>>>> relies on a separate early dialog (as documented currently in 
>>>>> WI3030).
>>>>>
>>>>> Second: 183, as any other provisional responses, apply only to 
>>>>> INVITE transactions. So you would never be able to 
>> apply the AoC 
>>>>> service than any INVITE generated service, that is, 
>> video, voice, 
>>>>> and MSRP sessions.
>>>>>
>>>>> [SG: I agree. The idea is that 183 would be used for AoC-S
>>>>> (INVITE) in addition to INFO/BYE/200OK BYE in case of AoC-D and 
>>>>> AoC-E. If you need to send AoC for a non-INVITE 
>> transaction (e.g. 
>>>>> MESSAGE,PUBLISH...), you would use 200 OK response to those 
>>>>> transactions MESSAGE/PUBLISH to convey the AoC information.]
>>>>>
>>>>>
>>>>>> 2/ Breaking end-to-end signalling
>>>>>> --------------------------------- The AS does not break 
>>>>>> anything, it simply adds service
>>>>> information to messages. This behaviour is very common 
>> in the work 
>>>>> we are doing in TISPAN.
>>>>>
>>>>> If the 183 has to split the dialog between the calling and the 
>>>>> called party, it is breaking the end-to-end signalling.
>>>>> While this situation can't be avoided in some cases, in 
>> general it 
>>>>> is desired to get away from it. It breaks any possible 
>> end-to-end 
>>>>> security, as a starting point.
>>>>>
>>>>> [SG: I agree with Christer's answer here.]
>>>>>
>>>>> If the service can be implemented while the AoC AS behaves as a 
>>>>> proxy, that would be an advantage for the implementation of the 
>>>>> service and the future compatibility of services.
>>>>>
>>>>>
>>>>> BR,
>>>>>
>>>>>
>>>>>
>>>>>      Miguel
>>>>>
>>>>>> Regards
>>>>>> sebastien
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Message d'origine-----
>>>>>> De : Miguel Garcia [mailto:[e-mail]]
>>>>>> Envoyé : lundi 30 janvier 2006 09:55 À : GARCIN Sebastien 
>>>>>> RD-CORE-ISS Cc : [e-mail] Objet : Re: 
>>>>>> [Sipping-tispan] Advice of Charge (AoC)
>>>>>>
>>>>>> GARCIN Sebastien RD-CORE-ISS wrote:
>>>>>>> Hi Miguel
>>>>>>>
>>>>>>> First I have some problems with the service definition as
>>>>> expressed in the draft-jesske-requirements-draft. The 
>> draft seems 
>>>>> to indicated the AoC service is always invoked by the 
>> served user. 
>>>>> Although this might be a valid case, this is not the 
>> only way to 
>>>>> invoke the service since it can be a permantent invocation. I 
>>>>> suggest that you copy and past the service definition as 
>>>>> documented by TISPAN in WI3030 instead of the text at the 
>>>>> beginning of §3.4.
>>>>>>
>>>>>> True, there is a permanent service indication that does not
>>>>> require any SIP signalling, thus, it does not have any protocol 
>>>>> impact. In the requirements we listed only those which 
>> we believe 
>>>>> they may have protocol impact.
>>>>>>> In other words the requirement "to signal to a network
>>>>> that the service is invoked" is optional. Additionnal I believe 
>>>>> that it should be optional for the UA to indicate whether it is 
>>>>> capable of understanding an AoC information sent by the network 
>>>>> (note that this is different from "invoking" the 
>> service). It is 
>>>>> important that the capabilities required from terminal 
>> is kept to 
>>>>> a minimum so as to make the AoC service possible for a 
>> wide range 
>>>>> of terminals.
>>>>>> I agree.
>>>>>>
>>>>>>> With regards to the delivery of the information, I don't
>>>>> agree the piggy backing solution has been demonstrated 
>> as "bad", 
>>>>> in my view it is the most elegant way I have seen and has the 
>>>>> advantage to require minimum capability to terminals.
>>>>>> Here I disagree. I am aware of two contexts where
>>>> piggyback has been
>>>>>> discussed: one is the IMS charging information, and you
>>>> know what? 
>>>>>> When 3GPP wanted to remove the usage of preconditions, all
>>>>> the problems where
>>>>>>   around the fact that "hmmmm... if we remove
>>>> preconditions, there
>>>>>> aren't enough messages to transport charging information,
>>>>> so we can't
>>>>>> remove preconditions". This is crap: creating artificial
>>>>> SIP messages
>>>>>> just to transfer required information.
>>>>>>
>>>>>> The other context where this was discussed was in the 
>>>>>> Session-dependent policies. After some comparisons and
>>>>> analysis, the
>>>>>> SIP WG decided to create a sideby channel for providing
>>>>> information of
>>>>>> the policies (the slides were presented in an IETF meeting,
>>>>> perhaps in
>>>>>> Seoul, don't quite remember exactly).
>>>>>>
>>>>>> Additionally, breaking the end-to-end signalling just
>>> to provide
>>>>>> sideby information is, in general, a bad idea. It should
>>>> be avoided.
>>>>>>
>>>>>>> Also I am surprised that you don't mention "MESSAGE" as
>>>>> solution since you advocated this solution in TISPAN meeting ??
>>>>>> Yes, MESSAGE is also an alternative to transport the
>>>>> information. So
>>>>>> we have the SUB/NOT, REFER, and MESSAGE.
>>>>>>
>>>>>>> Regards
>>>>>>> sebastien
>>>>>> BR;
>>>>>>
>>>>>>      Miguel
>>>>>>
>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : [e-mail] 
>>>>>>> [mailto:[e-mail]] De la part de
>>>>> Miguel Garcia
>>>>>>> Envoyé : lundi 30 janvier 2006 08:41 À : 
>>>> '[e-mail]'
>>>>>>> Objet : [Sipping-tispan] Advice of Charge (AoC)
>>>>>>>
>>>>>>> Hi all in the list.
>>>>>>>
>>>>>>> I would like to get opinions on solutions for implementing
>>>>> the Advice of Charge service.
>>>>>>> Requirements for this service are listed in the TISPAN
>>>>> requirements I-D, Section 3.4:
>> http://www.ietf.org/internet-drafts/draft-jesske-sipping-tispan-requi
>>>>>>> rements-02.txt
>>>>>>>
>>>>>>> When we discussed this service in Vancouver, Jonathan
>>>>> suggested to take a look at the SIP Interaction 
>> Framework to get 
>>>>> ideas. They are very good ideas in the SIP Interaction 
>> Framework, 
>>>>> but still I would like to get opinions.
>>>>>>> This service presents two problems to be solved:
>>>>>>>
>>>>>>> 1) How to signal to a network node that the service 
>> is invoked
>>>>>>> 2) How to transport the required information to the 
>> User Agent.
>>>>>>>
>>>>>>> According to the interaction framework, invocation could
>>>>> be signal by a combination of protocol elements,
>>>>> specifically: Allow REFER, Accept-Types with some specific XML 
>>>>> format, Contact with schemes: http, Contact with GRUU, 
>> Supported 
>>>>> with "tdialog", ... don't know what else.
>>>>>>> While that is valid, I think it presents three problems. 
>>>>> First, it is not possible to distinguish between "this 
>> is what the 
>>>>> UA supports" from "this is the invocation to the 
>> service". Second. 
>>>>> it makes the configuration of the initial filter criteria (to 
>>>>> trigger to the AoC Application server) a nightmare, because 
>>>>> instead of searching for one "item", we need to create 
>> comparisons 
>>>>> for four or five items. Third, this works as long as 
>> there is some 
>>>>> unique item to the service, which could be the type of body 
>>>>> declared in the Accept-Types, but as soon as we wanted to reuse 
>>>>> this body for some other service, we would run into trouble.
>>>>>>> One proposal to invoke the service was to define a new
>>>>> specific header, let's call it P-AoC, that contains some 
>>>>> parameters that define the service behavior. For 
>> example, it could 
>>>>> contain some preference of the reporting time or something like 
>>>>> that. Another alternative could be to use a subscription to an 
>>>>> event package, in which case, we are determining not to use a 
>>>>> REFER to an HTTP URI for conveying the information. A third 
>>>>> possibility is to define a specific feature tag, but I 
>> think this 
>>>>> isn't really a feature, but a whole service.
>>>>>>> On the delivery of information, we can think of a REFER to
>>>>> an HTTP URI or a SUB/NOT type of notification. Some folks have 
>>>>> been thinking of piggy-backing the information to SIP 
>> requests or 
>>>>> responses that "happens to pass by", but this solution 
>> is bad, as 
>>>>> it has been demonstrated with the charging stuff in 
>> IMS, besides 
>>>>> it does not meet the requirement of delivering 
>> information "a few 
>>>>> seconds after the communication has ended"
>>>>>>> (REQ-AoC-1). So I guess the choices are just REFER + HTTP
>>>>> URI or SUB/NOT.
>>>>>>> I am willing to hear comments that can provide the needed
>>>>> guidance to TISPAN.
>>>>>>> Best regards,
>>>>>>>
>>>>>>>            Miguel
>>>>>>>
>>>>> -- 
>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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
>>
> 
> _______________________________________________
> 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