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

["Hans Erik van Elburg \(RY/ETM\)" <[e-mail]>]

Inline... 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Miguel Garcia
Sent: Monday, January 30, 2006 12:20 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [Sipping-tispan] Advice of Charge (AoC)

There is a requirement that the AoC information can be delivered even a few seconds after the session has ended. You tell me how to send a BYE when a BYE has been already sent to dismiss the session.
HansErik> This is not required. Your confuisning with activation of MCID.

Second: don't be constrain to INVITE requests, this should be a general mechanism that is applicable not only to INVITE-initiated sessions. For instance, it could be used for PUBLISH requests, SUB/NOTIFY or MESSAGE services.
HansErik> A new P-header would not constrain to INVITE requests.

BR,

       Miguel

Darshan Bildikar wrote:
> Why not transfer the required AoC information as body in the SIP BYE 
> message when the session ends?
> 
> 
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Bemmel, Jeroen 
> van
> (Jeroen)
> Sent: Monday, January 30, 2006 2:39 PM
> To: 'Miguel Garcia'; GARCIN Sebastien RD-CORE-ISS
> Cc: [e-mail]
> Subject: RE: [Sipping-tispan] Advice of Charge (AoC)
> 
> 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
>>
> 
> _______________________________________________
> 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

_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan