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

["Elwell, John" <[e-mail]>]

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