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

["Avasarala Ranjit-A20990" <[e-mail]>]

Hi Miguel

By XCAP I mean using HTTP. Yes we could use HTTP GET operation to get the AoC document. 


Regards
Ranjit

-----Original Message-----
From: Miguel Garcia [mailto:[e-mail]] 
Sent: Monday, January 30, 2006 4:53 PM
To: Avasarala Ranjit-A20990
Cc: [e-mail]; Bemmel, Jeroen van (Jeroen); GARCIN Sebastien RD-CORE-ISS; [e-mail]
Subject: Re: [Sipping-tispan] Advice of Charge (AoC)

I agree we would need an XML document that conveys the information that, eventually, it is interpreted and displayed to the user.

The other thing: are you suggesting to use XCAP for convey the AoC XML document? I think XCAP is nice for doing XML document manipulation, but not for displaying information. Specifically, we would need to do GET operations of the full XML document, in which case, I don't think we need XCAP at all, but just a pure HTTP GET.

/Miguel

Avasarala Ranjit-A20990 wrote:
> Hi
> 
> I feel there needs a format for AoC message, like an XML package. Then this info can be sent either in NOTIFY if the served user subscribes to the AoC service or Aoc XML doc can be sent using XCAP instead of putting it any SIP message. 
> 
> 
> Regards
> Ranjit
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Darshan Bildikar
> Sent: Monday, January 30, 2006 2:51 PM
> To: 'Bemmel, Jeroen van (Jeroen)'; 'Miguel Garcia'; 'GARCIN Sebastien RD-CORE-ISS'
> Cc: [e-mail]
> Subject: 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

-- 
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