3 Aug 2004 18:49
: FW: Diameter Credit Control - IESG Evaluation, Allison Mankin's comments
<john.loughney <at> nokia.com>
2004-08-03 16:49:36 GMT
2004-08-03 16:49:36 GMT
Text to clear Allison's DISCUSS, still waiting on response. -------------------------- Hello, thank you for your comments. Please see the answers and proposals for improved text below and let us know whether these corrections and clarifications will address your concerns. Best Regards, Harri Hakala Leena Mattila Juha-Pekka Koskinen Marco Stura John Loughney ----------------------------------------------------------------- Allison Mankin Discuss: - The Subscription-Id-Type AVPs are a very limited set and do not appear extensible: what about this application for interoperating pres: uri's or other identifiers in future? Another case like this is the User-Equipment-Identifier, which allows only 3GPP mobiles and wireless. This is inappropriate in a general AAA document. Answer: Actually the AVPs are extensible. Both the Subscriptio-Id-Type and the User-Equipment-Info-Type AVPs are of type enumerated, it is sufficient to define and document new values to extend the AVPs to cover other needs. Basically we have defined those AVPs also thinking to extensibility since we cannot cover all the possible identifier that may pop-up in the future. Concerning the User-Equipment-Info AVP, we have defined MAC, EUI64 and MODIFIED_EUI64 that should cover also a broad range of wired (non-3GPP) terminals. Overall we believe that the AVPs in question are not 3GPP mobiles and wireless specific, rather generic enough to cover other environments as well. Discuss: - The WG needed to think more broadly about SIP. The SIP example works as expected in the 3GPP-enforced environment because the proxy can measure the quota, but in open environments, the proxy at best will see the BYE (and possibly might not see that). Flow II must state in a careful final paragraph that the degree of credit control measuring of the media by the proxy depends on the business model design used in setting up the end system and proxies in the SIP network. Answer: The intention of the flows example is just to illustrate simple examples for the usage of the DCCA. The purpose of those flows is not to define how SIP work in different environments, it should perhaps stated that the SIP signaling is inacurate and the focus is on credit control messages. If a service provider want to offer prepaid services for SIP sessions based on time usage, it should make sure that all requests within the dialog created by that INVITE traverse the proxy that provide prepaid services. Otherwise no prepaid services (usage based) can be offered at all. Here is a proposal for a new text, perhaps you could suggest even more appropriate text should you disagree with our proposal. New text proposal to be added right after the diagram: This is an example of Diameter Credit Control for SIP sessions. While the flow focuses on illustrating the usage of credit-control messages, the SIP signaling is inaccurate and the diagram is not by any means an attempt to define a service provider's SIP network. However, for the sake of this example some assumption is made as discussed in the next paragraph. Typically, prepaid services based e.g. on time usage for SIP session require an entity in the service provider network to intercept all the requests within the SIP dialog in order to detect events, such as session establishment and session release, which are essential to perform credit-control operations with the credit control server. It is, therefore, assumed in this example that the SIP Proxy record-route since the initial INVITE to make sure that all the future requests in the created dialog traverse through it. Finally, the degree of credit control measuring of the media by the proxy depends on the business model design used in setting up the end system and proxies in the SIP network. Discuss: - Flow V and VII need a bigger SIP picture. In V, the INVITE is to B, or to a B2BUA that is meant to intercept a price inquiry? This is a new SIP service. Flow VII describes use of a SIP controller, which is probably 3PCC, but that needs to be shown, the call establishment would need to be shown. Answer: Flow V The INVITE is sent to B. The term SIP controller was taken from the RFC 3725, not sure whether this term is appropriate here. The intention in this example is that this "SIP controller" just buffer the INVITE, just as it would do a proxy for an ordinary quota request, until the AoC transaction is performed. When the user accept the charges the original INVITE is sent forward toward the destination. Again, the intention of the flows example is just to illustrate simple examples for the usage of the DCCA features. Perhaps similar text as proposed above is also suitable here? New text proposal to be added right after the diagram (Flow V): This is an example of Diameter Credit Control for SIP sessions. While the flow focuses on illustrating the usage of credit-control messages, the SIP signaling is inaccurate and the diagram is not by any means an attempt to define a service provider's SIP network. UA A sends an INVITE with SDP to B (1). Flow VII SIP controller is here 3PCC, again the term was taken from RFC 3725. Perhaps we could refer to RFC 3725 and mention that best current practices for 3PCC are defined there. Also in this flow we choose to keep the SIP signaling at very high level since we are not defining SIP in this document, we are just doing high level examples to illustrate DCCA functionalities. What about this text proposal? Figure A.7 is an example of the graceful service termination for a SIP call. It is assumed the call is set up so that the controller is in the call as a B2BUA (Back to Back User Agent) performing third party call control (3PCC). Note that the SIP signaling is inaccurate since the focus of this flow is in the graceful service termination and credit control authorization, best practices for 3PCC are defined in [RFC 3725]. We could then add RFC 3725 in the informational references. Discuss: - Recommendation on flows V and VII: Jon and I should email you as to whether to clean them up, remove them, or annotate them. Answer: OK with us. Please consider the above proposals while making your decision.