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

"Martinez-Rebordosa, Anna" <Anna.Martinez-Rebordosa@t-com.net> Tue, 31 January 2006 15:21 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 1F3xK1-0002jd-Ri; Tue, 31 Jan 2006 10:21:33 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3xK0-0002ht-R8 for sipping-tispan@megatron.ietf.org; Tue, 31 Jan 2006 10:21:32 -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 KAA25639 for <sipping-tispan@ietf.org>; Tue, 31 Jan 2006 10:19:50 -0500 (EST)
Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3xUt-000767-D2 for sipping-tispan@ietf.org; Tue, 31 Jan 2006 10:32:48 -0500
Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 31 Jan 2006 16:21:05 +0100
Received: by S4DE8PSAANQ.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <D9K5LHY8>; Tue, 31 Jan 2006 16:21:04 +0100
Message-Id: <8DC32D679F3D914F9D52F954F7333B2A0173A741@S4DE8PSAAGL.blf.telekom.de>
From: "Martinez-Rebordosa, Anna" <Anna.Martinez-Rebordosa@t-com.net>
To: mhammer@cisco.com, hanserik.van.elburg@ericsson.com, john.elwell@siemens.com, sebastien.garcin@francetelecom.com, Miguel.An.Garcia@nokia.com
Subject: AW: [Sipping-tispan] Advice of Charge (AoC)
Date: Tue, 31 Jan 2006 16:21:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 713965ef965c5660ee5d9a664a73ef4a
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

Hi Mike,

Thanks, Mike. Yes, sorry, that was my mistake to include this text here. This text is valid, only in the case of being in a PSTN/ISDN domain, which is not under our discussion issue. I just make a copy/paste requirements on the three types of Aoc from the PSTN/ISDN to clarify them. 

You are right, we should concentrate on the first statement of "The network shall provide the charging information and transfer it to the served user in an appropriate message.". The statements about the message clearing on the requirements below should be ingored for our purpose.


Anna



-----Ursprüngliche Nachricht-----
Von: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] 
Gesendet: Dienstag, 31. Januar 2006 16:13
An: Martinez Rebordosa, Anna; hanserik.van.elburg@ericsson.com; john.elwell@siemens.com; sebastien.garcin@francetelecom.com; Miguel.An.Garcia@nokia.com
Cc: sipping-tispan@ietf.org
Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)


Hmmm...  The core idea here is that the user needs to be informed. 

I think this statement from b. below got it absolutely right:  "The network shall provide the charging information and transfer it to the served user in an appropriate message."

But, can someone justify the additional statements:  (in b.) "the network shall send the charged amount (zero) in a call control message clearing the call." (in c.) "The network shall send the charging information to the served user in one of the call control messages clearing the call."  Why???

This seems to unnecessarily constrain the solution.  Could someone explain to me why this solution embedded in requirement is justified?  Or, can we upgrade this with the knowledge that other methods of solution are possible?

Mike


> -----Original Message-----
> From: Martinez-Rebordosa, Anna 
> [mailto:Anna.Martinez-Rebordosa@t-com.net] 
> Sent: Tuesday, January 31, 2006 8:58 AM
> To: hanserik.van.elburg@ericsson.com; 
> john.elwell@siemens.com; Michael Hammer (mhammer); 
> sebastien.garcin@francetelecom.com; Miguel.An.Garcia@nokia.com
> Cc: sipping-tispan@ietf.org
> Subject: AW: [Sipping-tispan] Advice of Charge (AoC)
> 
> 
> John,
> 
> Totally agree with Hans Erik about the trusted AOC information. 
> 
> Your other question about session-related charging 
> information. Yes, I pressume that the charging information to 
> be provided to the served user applies only to the session 
> been stablished. The invocation of AoC service is also done 
> at the session stablishment. 
> 
> For better understanding on AoC here some definitions from 
> the ETS 300 182-1:
> 
> Three AOC supplementary services exist:
> a)	Charging information at call set-up time (AOC-S)
> 
> 	When the AOC-S supplementary service is activated, the 
> network shall provide the user with information about the 
> charging rates at call establishment. In addition, the 
> network shall inform the served user if a change in charging 
> rates takes place during the call.
> The network shall provide the charging information during 
> call establishment or at the latest at call connection. When 
> there is a change in the charging rate during the call, the 
> network shall send information about the new charging rate to 
> the served user
> 
> b)	Charging information during the call (AOC-D)
> When the AOC-D supplementary service is activated, the 
> network shall provide the user with charging information for 
> a call during the active phase of a call. The network shall 
> provide the charging information and transfer it to the 
> served user in an appropriate message. The supplied charging 
> information shall be provided as a cumulative charge incurred 
> so far for the call (i.e. charges recorded from the start of 
> the call and until the moment the charging information is 
> sent to the served user).
> When the call is released, the network shall send the 
> recorded charges for the call to the served user in one of 
> the call control messages clearing the call.
> If the network has determined that the call is free of 
> charge, then the network shall send a free-of-charge 
> indication in the first subsequent message sent to the served 
> user. The network shall not send any further charging 
> information during the call. When the call is released, the 
> network shall send the charged amount (zero) in a call 
> control message clearing the call.
> 
> c)	Charging information at the end of the call (AOC-E)
> 
> 	When the AOC-E supplementary service is activated, the 
> network shall provide the served user with charging 
> information indicating the recorded charges for a call when 
> the call is released. The network shall send the charging 
> information to the served user in one of the call control 
> messages clearing the call.
> 
> 
> 
> I hope that can clarify some questions.
> BR,
> Anna
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Hans Erik van Elburg (RY/ETM) 
> [mailto:hanserik.van.elburg@ericsson.com]
> Gesendet: Dienstag, 31. Januar 2006 14:46
> An: Elwell, John; Martinez Rebordosa, Anna; 
> mhammer@cisco.com; sebastien.garcin@francetelecom.com; 
> Miguel.An.Garcia@nokia.com
> Cc: sipping-tispan@ietf.org
> Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)
> 
> 
> AOC information header is inserted by an AS in the trust 
> domain. Further it does not reveal any identity information, 
> only tariff informatrion that is applicable for the receiving 
> user. It is the AS of the served user that inserts this 
> information for the served users UE or access gateway to 
> render to the user and for bookkeeping purposes.
> 
> False information received from untrusted networks should 
> either be removed or rejected at the border of the trust domain.
> 
> This is the same kind of trust relations that are used to 
> know that for example P-Asserted-Identity is authenticated by 
> the network and by nobody else.
> 
> /Hans Erik
> 
> -----Original Message-----
> From: sipping-tispan-bounces@ietf.org 
> [mailto:sipping-tispan-bounces@ietf.org] On Behalf Of Elwell, John
> Sent: Tuesday, January 31, 2006 1:55 PM
> To: Martinez-Rebordosa, Anna; mhammer@cisco.com; 
> sebastien.garcin@francetelecom.com; Miguel.An.Garcia@nokia.com
> Cc: sipping-tispan@ietf.org
> Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
> 
> Anna,
> 
> Thanks, so the middle option (AOC-D) would tend to steer us 
> in the direction of SUBSCRIBE/NOTIFY rather than HTTP GET, 
> because there can be multiple notifications.
> 
> These three types of AOC are all session-related, yet there 
> was some recent discussion about AOC applied to other SIP 
> messaging, not just session-related. Can we assume that AOC 
> is indeed limited to session-related charges?
> 
> Some postings to this list have been discussing sending the 
> charge information in the context of the INVITE-initiated 
> dialog for the session.
> An intermediary would insert the charge information, and this 
> then gives rise to questions about security. What are the 
> authentication requirements for the charge information? 
> Depending on requirements, insertion of this information by a 
> proxy may be problematic. A proxy can't insert a body. It can 
> insert a header, of course, but that header would not be 
> covered by the integrity protection that the Identity header 
> provides. SUBSCRIBE/NOTIFY can draw upon standard security 
> measures much more easily than in-dialog information.
> 
> John
> 
> > -----Original Message-----
> > From: Martinez-Rebordosa, Anna
> > [mailto:Anna.Martinez-Rebordosa@t-com.net]
> > Sent: 31 January 2006 09:25
> > To: Elwell, John; mhammer@cisco.com;
> > sebastien.garcin@francetelecom.com; Miguel.An.Garcia@nokia.com
> > Cc: sipping-tispan@ietf.org
> > Subject: AW: [Sipping-tispan] Advice of Charge (AoC)
> > 
> > John,
> > Aoc is defined on three types: 
> > - AOC-S: served user received the information at the time of 
> > establischment the session.
> > - AOC-D: served user received the information during the session. 
> > Every t seconds. t is a network operator option.
> > -AOC-E: served user received the information at the end of the 
> > session.
> > 
> > I hope this clarifies a little bit more.
> > 
> > Anna
> > 
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: Elwell, John [mailto:john.elwell@siemens.com]
> > Gesendet: Montag, 30. Januar 2006 22:29
> > An: Michael Hammer (mhammer); GARCIN Sebastien RD-CORE-ISS; Miguel 
> > Garcia
> > Cc: sipping-tispan@ietf.org
> > Betreff: RE: [Sipping-tispan] Advice of Charge (AoC)
> > 
> > 
> > Michael,
> > 
> > It seems to me that HTTP/GET would be a good choice if a single 
> > immediate response can be expected. SUBSCRIBE/NOTIFY has some clear 
> > benefits if there is likely to be a delay before the information is 
> > available (so the subscriber will receive a 2xx response 
> and await a 
> > NOTIFY
> > request) or if the
> > information might need to be updated during the subscription period 
> > (multiple NOTIFY requests). Can TISPAN people please 
> clarify what is 
> > required?
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> > > Sent: 30 January 2006 14:58
> > > To: GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
> > > Cc: sipping-tispan@ietf.org
> > > Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
> > > 
> > > All,
> > > 
> > > A comment from the peanut gallery.
> > > 
> > > I am concerned that precedents from a single media type service 
> > > might unduly constrain a solution that uses multiple media types 
> > > simultaneously, some of which could be session-oriented, some of 
> > > which might be "connectionless".
> > > All this talk of piggy-backing and use of 183 does not seem to be 
> > > generally useful in all situations.
> > > 
> > > I would suggest that a solution that is general to all types of 
> > > services and attempts to be as decoupled as possible from those 
> > > services would minimize the possibility of feature interactions 
> > > between AoC and other features/services.
> > > 
> > > That said, the essence of AoC is a request for information that 
> > > seems to be a natural fit for a Subscribe/Notify type of 
> operation 
> > > for request and delivery.  A particular dialog or message will 
> > > likely need to have an associated address from which this 
> > > information can be requested.  One or more 
> values/addresses can be 
> > > added to message/INVITE to enable a UA to know where to send the 
> > > Subscribe.  The accounting element will need to be able 
> to identify 
> > > the dialog or message and bind that to the charge or charge rate, 
> > > which seems to be the nature of an Event package.
> > > 
> > > I suspect that AoC will not be the last type of "Event" 
> that will be 
> > > needed for SIP.  Leveraging a general mechanism would be 
> better than 
> > > reinventing event reporting for each of N "features" that will 
> > > arise.  Talk of performance needs to keep a broad 
> perspective on the 
> > > overall system.
> > > 
> > > Mike
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: sipping-tispan-bounces@ietf.org 
> > > > [mailto:sipping-tispan-bounces@ietf.org] On Behalf Of GARCIN 
> > > > Sebastien RD-CORE-ISS
> > > > Sent: Monday, January 30, 2006 8:56 AM
> > > > To: Miguel Garcia
> > > > Cc: sipping-tispan@ietf.org
> > > > Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
> > > > 
> > > > Miguel,
> > > > 
> > > > Please see answers below [SG]
> > > > 
> > > > Regards,
> > > > sebastien
> > > > 
> > > > -----Message d'origine-----
> > > > De : Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]
> > > > Envoyé : lundi 30 janvier 2006 12:30 À : GARCIN Sebastien 
> > > > RD-CORE-ISS Cc : sipping-tispan@ietf.org Objet : 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.
> > > > 
> > > > [SG: Why is 183 more artificial than MESSAGE / INFO / 
> or anything 
> > > > else ? The 183 does not delay the session in my view since it 
> > > > relies on a separate early dialog (as documented currently in 
> > > > WI3030).
> > > > 
> > > > 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.
> > > > 
> > > > [SG: I agree. The idea is that 183 would be used for AoC-S
> > > > (INVITE) in addition to INFO/BYE/200OK BYE in case of AoC-D and 
> > > > AoC-E. If you need to send AoC for a non-INVITE 
> transaction (e.g. 
> > > > MESSAGE,PUBLISH...), you would use 200 OK response to those 
> > > > transactions MESSAGE/PUBLISH to convey the AoC information.]
> > > > 
> > > > 
> > > > > 
> > > > > 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.
> > > > 
> > > > [SG: I agree with Christer's answer here.]
> > > > 
> > > > 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-requi
> > > > >> rements-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
> > > 
> > 
> > _______________________________________________
> > 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
> 

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