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

[Miguel Garcia <[e-mail]>]

So how are you going to create a post-paid application, which requires 
to send the information after the session is dismissed, with the 
in-dialog approach? Once the BYE is sent, there aren't more messages to 
receive, so this comes back to one my problems: you need to artificially 
twist here and there to get more session messages for something that is 
unrelated.

I don't bye the argument of the performance either.

/Miguel

Darshan Bildikar wrote:
> Would it not be better to use an "in-dialog" "piggybacking" approach as
> suggested?
> 
> Creating a side dialog and using an HTTP GET might create an unnecessary
> performance over head. 
> 
> As an example, I'm thinking of an IP post paid application (for which AoC
> would be really useful!) with a 1 million user database that needs to
> support 200 BHCA. 
> 
> Getting the AoC information without any extra signaling would be helpful to
> say the least!
> 
> 
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Miguel Garcia
> Sent: Monday, January 30, 2006 5:00 PM
> To: GARCIN Sebastien RD-CORE-ISS
> Cc: [e-mail]
> Subject: 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.
> 
> 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.
> 
>> 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. 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-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