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

"Hans Erik van Elburg \(RY/ETM\)" <hanserik.van.elburg@ericsson.com> Tue, 31 January 2006 11:36 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3toQ-0007QH-Cu; Tue, 31 Jan 2006 06:36:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3toP-0007PR-UH for sipping-tispan@megatron.ietf.org; Tue, 31 Jan 2006 06:36:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07696 for <sipping-tispan@ietf.org>; Tue, 31 Jan 2006 06:34:58 -0500 (EST)
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3tzA-0007oJ-Q7 for sipping-tispan@ietf.org; Tue, 31 Jan 2006 06:47:53 -0500
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B304D611; Tue, 31 Jan 2006 12:36:18 +0100 (CET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 12:36:18 +0100
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jan 2006 12:36:18 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
Date: Tue, 31 Jan 2006 12:36:16 +0100
Message-ID: <CAC481363DB73049924DDDCFC1AC60A6023A8838@esealmw109.eemea.ericsson.se>
Thread-Topic: [Sipping-tispan] Advice of Charge (AoC)
Thread-Index: AcYll+KDUEIsLFqlRXy9Pv9jpmSkTgAwm/Ig
From: "Hans Erik van Elburg (RY/ETM)" <hanserik.van.elburg@ericsson.com>
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>, darshanb@huawei.com
X-OriginalArrivalTime: 31 Jan 2006 11:36:18.0154 (UTC) FILETIME=[8D0624A0:01C6265A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cbb41f2dbf0f142369614756642005e3
Content-Transfer-Encoding: quoted-printable
Cc: sipping-tispan@ietf.org
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

This is not required so the solution does not need to solve that problem.

We are talking about delivering the information beginning, during and at the end of the call.

/Hans Erik 

-----Original Message-----
From: sipping-tispan-bounces@ietf.org [mailto:sipping-tispan-bounces@ietf.org] On Behalf Of Miguel Garcia
Sent: Monday, January 30, 2006 1:22 PM
To: darshanb@huawei.com
Cc: sipping-tispan@ietf.org
Subject: Re: [Sipping-tispan] Advice of Charge (AoC)

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: sipping-tispan-bounces@ietf.org
> [mailto:sipping-tispan-bounces@ietf.org] On Behalf Of Miguel Garcia
> Sent: Monday, January 30, 2006 5:00 PM
> To: GARCIN Sebastien RD-CORE-ISS
> Cc: sipping-tispan@ietf.org
> 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:Miguel.An.Garcia@nokia.com]
>> Envoyé : lundi 30 janvier 2006 09:55
>> À : GARCIN Sebastien RD-CORE-ISS
>> Cc : sipping-tispan@ietf.org
>> 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 : sipping-tispan-bounces@ietf.org
> [mailto:sipping-tispan-bounces@ietf.org] De la part de Miguel Garcia
>>> Envoyé : lundi 30 janvier 2006 08:41 À : 'sipping-tispan@ietf.org'
>>> 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-requir
> ements
> -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:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan

_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan