1 / 6

Diameter Credit Control Application

Diameter Credit Control Application. draft-ietf-aaa-diameter-cc-05.txt John Loughney. Allison’s DISCUSS.

yporter
Télécharger la présentation

Diameter Credit Control Application

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Diameter Credit Control Application • draft-ietf-aaa-diameter-cc-05.txt • John Loughney

  2. Allison’s 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. • AVPs are extensible, for example, User-Equipment-Info AVP, we have defined MAC, EUI64 and MODIFIED_EUI64 that should cover also a broad range of wired (non-3GPP) terminals. • 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. • Current text just example, will update the text to be more general. • 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. • Current text just example, will update the text to be more general. • Recommendation on flows V and VII: Jon and I should email you as to whether to clean them up, remove them, or annotate them. • Waiting on follow-up, removing flows would be OK.

  3. Thomas Narten’s DISCUSS / IANA • Discuss on IANA Issues, also raised by IANA. • Text proposed and accepted by IANA.

  4. Ted Hardie - DISCUSS • I believe Section 4.1 needs some clean up to provide useful guidelines for interoperability.  • Agree, the section needs some restructure to give better guidence. Proposed text, which is OK with Ted. • It is not clear to me what the client requirements are for 5.5.  If, for example, a client is using this mechanism to manage voice minutes on a mobile phone, does the potential for a Server-initiated RAR imply that the client must have data traffic and this service enabled at all times, in case it receives such a request? • Added text clarification. • Need definition of "credit fragmentation" is mentioned in this section. • Added definition.

  5. Next Steps • After clearing Allison’s discuss, update the draft. • Make a small editorial pass & resubmit the draft.

  6. Other • Glenn Zorn – add Service-Identifier to CER / CEA • No action • Ahmad Muhanna – new cause value as "tariff change not supported“ • No action • Some small editorial fixes.

More Related