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

["Michael Hammer \(mhammer\)" <[e-mail]>]

Keith,

Perhaps if an IMS proxy path and an ISDN switch path look similar, that could be.

I am wondering whether, with multiple networks and multiple signaling and media paths, there wouldn't be a centralized accounting/charging function that Publishes the value of a "call" that then gets Notified to the one or more responsible parties?

Mike


> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[e-mail]] 
> Sent: Wednesday, February 01, 2006 11:46 AM
> To: Martinez-Rebordosa, Anna; 
> [e-mail]; [e-mail]; 
> Michael Hammer (mhammer); [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