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

[Miguel Garcia <[e-mail]>]

Can I gut an opinion of why INFO suits for this purpose whereas MESSAGE 
doesn't? MESSAGE's intention is to display some real-time information to 
the user, which is exactly what we are trying to achieve.

INFO has the problem that it breaks the end-to-end dialog, because it 
requires the AS to become a B2BUA.

/Miguel

Bemmel, Jeroen van (Jeroen) wrote:
> 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
>>

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