[Sipping-tispan] Advice of Charge (AoC)

[Miguel Garcia <[e-mail]>]

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