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

["Jesske, R" <[e-mail]>]

We have different service capabilities when the AoC information will be sent.

1. before the call starts 
2. during the call 
3. with the end of the call 

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Darshan Bildikar [mailto:[e-mail]] 
> Gesendet: Montag, 30. Januar 2006 10:21
> An: 'Bemmel, Jeroen van (Jeroen)'; 'Miguel Garcia'; 'GARCIN 
> Sebastien RD-CORE-ISS'
> Cc: [e-mail]
> Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)
> 
> 
> Why not transfer the required AoC information as body in the 
> SIP BYE message
> when the session ends?
> 
> 
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Bemmel, 
> Jeroen van
> (Jeroen)
> Sent: Monday, January 30, 2006 2:39 PM
> To: 'Miguel Garcia'; GARCIN Sebastien RD-CORE-ISS
> Cc: [e-mail]
> Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
> 
> Miguel,
> 
> It seems that the INFO method (RFC2976) could be used for 
> this purpose too.
> I would argue that it matches better than MESSAGE (RFC3428), 
> which is not
> intended for this kind of service
> 
> Regards,
> 
> Jeroen
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Miguel Garcia
> > Sent: Monday, January 30, 2006 9:55 AM
> > To: GARCIN Sebastien RD-CORE-ISS
> > Cc: [e-mail]
> > Subject: 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-tispa
> > n-requirements-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