Patent Application
20050096012
This invention relates generally to Internet Protocol (IP) compatible sessions and more particularly to authentication and billing activities.
IP based communication systems are well known and many well-established protocols and interfaces are defined to facilitate a variety of communications. For example, remote authentication dial-in user service (RADIUS)-compatible servers (such as authentication, authorization, and accounting servers (AAA's)) are known that utilize RADIUS communication protocols to facilitate authentication of a given user with respect to a given communication session. There are also ongoing proposals to develop and offer additional IP-compatible functionality and/or services. For example, near-real-time multicast communication services, such as so-called walkie-talkie services that permit two-way communications between or amongst two or more grouped mobile units, have been proposed.
At present, such services are typically based on session initiation protocol (SIP) call establishment and management methodologies. This has the benefit of permitting, for example, reuse of a widely dispersed existing SIP infrastructure. This SIP infrastructure can serve to support voice-over-Internet-Protocol (VoIP) calls, instant messaging, video conferencing, data streaming, and so forth amongst predefined groups of users. When facilitating such services, user authorization and/or billing are often significant design requirements. SIP in turn provides specific ways by which authentication can be achieved (one such mechanism, entitled “HTTP Digest Authentication,” is defined in the RFC2617 specification).
Unfortunately, though widespread, SIP does not represent a universal solution and platform enabler. Many system infrastructures, and especially IP-based systems, use alternative mechanisms. For example, to facilitate user authorization, IP-based systems often employ RADIUS-compatible servers such as the relatively ubiquitous AAA server. Such RADIUS servers do not use an SIP-compatible communication mechanism and in particular do not support present SIP authorization procedures. Such circumstances make it difficult to involve a RADIUS server in the SIP authentication process. For example, no useful way to readily translate an SIP-friendly HTTP digest expression into a RADIUS-friendly CHAP-style digest exists, and in particular there have been no useful suggestions of how to readily derive an SIP password from the so-called CHAP-based chap_secret expression.
In a similar manner, presently proposed or commercially available near-real-time multicast communication service servers do not support RADIUS protocols and communication methodologies. Consequently, billing for services such as near-real-time multicast communication services often tends to be based upon a fixed fee as the per-call information that would be necessary to inform another approach is simply not usually available.
It should therefore be evident that existing RADIUS servers, including AAA servers as are commonly otherwise used to facilitate various IP-based communications, are not readily adapted for use with SIP-based services such as near-real-time multicast communication services (including but not limited to so-called walkie-talkie services). Instead, authorization and authentication can present a difficult challenge and billing is often relegated to a relatively one-dimensional and simple construct for lack of a suitable support mechanism.
The above needs are at least partially met through provision of the authentication and/or billing mediation service apparatus and method described in the following detailed description, particularly when studied in conjunction with the drawings, wherein:
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are typically not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention.
Generally speaking, pursuant to these various embodiments, to facilitate or to compliment authentication, an implementing platform (such as a physical or virtual mediation server) receives SIP-compatible authentication message information as corresponds to an authentication message as sourced by a given subscriber and converts that SIP-compatible authentication message information into corresponding RADIUS protocol-compatible authentication message information. The latter is then suitable for use to facilitate authenticating the corresponding subscriber. Depending upon the embodiment, an SIP-compatible proxy can be used to receive the SIP-compatible authentication message information. In a preferred embodiment a RADIUS server uses the RADIUS protocol-compatible authentication message to facilitate the authentication process. In particular, this permits a RADIUS server to facilitate authentication of a given subscriber with respect to usage of a particular communication service such as a near-real-time multicast communication service.
Also pursuant to these various embodiments, billing information as pertains to such communication services as are provided to a given subscriber can be generated and then provided to the RADIUS server. For example, billing information as relates to provision of a near-real-time multicast communication service can be forwarded via an appropriate intermediary.
So configured, a RADIUS server, such as an AAA server, can be readily employed to support both SIP-based subscriber units (and their corresponding infrastructure) and considerable flexibility regarding billing for the provision of more complex services, such as near-real-time multicast communication services can more readily be accommodated. This in turn will likely facilitate a more rapid and widespread fielding of such services to the mutual benefit of both users and system operators.
Referring now to
This mediation server 10, in a preferred embodiment, has an SIP compatible interface to facilitate communications regarding near-real-time multicast communication services with, for example, another SIP platform such as, but not limited to, an SIP proxy 11. Various SIP-friendly authentication protocols exist as offered by companies such as Cisco. As one specific example, this SIP compatible interface can comprise a 3Q compatible interface as offered by UTStarcom to thereby support SIP-based 3Q communications regarding, for example, authentication of a mobile unit 14 seeking access to a near-real-time multicast communication service. (Those skilled in the art will recognize that 3Q comprises a proprietary AAA protocol and simply represents one illustrative example of an SIP compatible protocol and exchange vehicle; though 3Q will be referred to from time to time herein for ease of illustrating and exemplifying these embodiments, it will be understood that all such references shall be interpreted to include all presently known or hereafter developed SIP compatible connectivity tools. Those skilled in the art will also recognize that such a mobile unit 14 may often also communicate with such an SIP proxy 11 via one or more intermediary platforms such as, but not limited to, a packet data serving node 15.)
In addition, or in lieu of the SIP compatible interface, in a preferred approach the mediation server 10 can have a near-real-time multicast communications services server interface to permit compatible communications with, for example, a near-real-time multicast communications service(s) server 13 (which in turn may support, for example, so-called walkie talkie style communications that include point to point communications, point to multipoint communications, or both amongst the participants of one or more predefined groups). So configured, the mediation server 10 can obtain billing information from the near-real-time multicast communications service(s) server 13 regarding corresponding services as are provided to one or more subscribers. As will be detailed below, such an exchange of information can be facilitated via a file transfer mechanism (such as HTTP, FTP, NFS, and the like); that is, billing information as stored and/or aggregated by the near-real-time multicast communications service(s) server 13 in a local (or remote) memory can be accessed and called, in whole or in part, by the mediation server 10 using such transfer mechanisms in a manner otherwise generally well understood in the art.
Such billing information can assume a wide variety of billable events and/or criteria including, but not limited to:
With access to such billing information from the near-real-time multicast communication server 13, the mediation server 10 can, for example, serve to process such billing information to provide temporally parsed billing information as corresponds to portions of a given near-real-time multicast session (for example, individual transmissions as comprise discrete portions of a larger multi-party multi-transmission communication can be separately treated via this approach). As another example, the mediation server 10 can process such billing information to provide parsed billing information as individually corresponds to individual participants of a given near-real-time multicast session (to thereby permit, for example, each participant to be individually billed for part or all of a multi-party communication of this sort). Such examples are illustrative only and other processing options will occur to those skilled in the art. Such alternatives should be considered as being within the scope of these teachings.
So configured, the mediation server 10 can communicate compatibly regarding authentication information with SIP compatible devices/systems and/or can communicate compatibly with near-real-time multicast communications service(s) servers 13 regarding billing information. In a preferred embodiment, the mediation server 10 will further include a RADIUS server interface to facilitate providing information to a RADIUS server 12 (such as an AAA) regarding authentication communications and/or billing information as pertain to the facilitation and offering of near-real-time multicast communications services. (Depending upon the operational environment and architecture, other system elements, such as a packet data serving node 15, may also be able to communicate with this RADIUS server 12 in a manner otherwise understood in the art.)
Such a configuration permits the mediation server 10 to receive authentication and/or billing information as pertains to the offering of near-real-time multicast communications services and to compatibly forward that information to a RADIUS server that can utilize that information to facilitate communications via such a service. For example, the RADIUS server 12 can utilize authentication messages as sourced by an SIP-based mobile unit 14 and as translated via the mediation server 10 to a corresponding RADIUS presentation. In a similar manner, billing information as collected from a near-real-time multicast communications service(s) server 13 can be provided, in a processed or unprocessed form, to the RADIUS server to thereby facilitate billing in accordance with the billing criteria and plans of the service provider.
Such a platform, or such other platform as may be suitable to meet the needs of a given context and application, can serve to effect processes such as those set forth in
It may nevertheless be useful and desirable, however, to have the mobile unit share a separate SIP password with the mediation server noted above to thereby effect specific permission to let the mobile unit use session initiation protocol, so that, for example, the SIP infrastructure can subsequently decide whether or not to permit the mobile unit to ultimately use the near-real-time multicast communication service (where, for example, the SIP infrastructure may have predefined limitations regarding supplemental costs that can be assumed with respect to resource usage of the mobile unit). This process 20 can provide for conversion 22 of the SIP compatible authentication message information into corresponding RADIUS protocol compatible authentication message information (which conversion occurs, for example, in an authentication mediation server). The latter is then preferably used 23 (for example, by a RADIUS compatible server such as an AAA server) to facilitate authentication of the given subscriber. For example, the given subscriber can be authenticated with respect to usage of a particular communication service (such as but not limited to a near-real-time multicast communication service facilitated as desired to support one-to-one and/or one-to-many group voice communication services including VoIP communication services).
As one example, the mediation server can share a corresponding CHAP password with, for example, the RADIUS compatible AAA in order to essentially authenticate the mobile unit (though, at least in some instances, this authentication will be relatively procedural in nature). Viewed another way, authentication occurs when the mediation server returns the mobile unit's SIP password to the corresponding SIP proxy such that the SIP proxy can then perform standard SIP authentication for the mobile unit.
Referring momentarily to
The mediation server can then transmit the SIP password back to the SIP proxy using an appropriate 3Q authorization response message 33. The SIP proxy and the mobile unit can then engage in a short series of communications 34 wherein the SIP proxy transmits a 401 authorization required message to the mobile unit (which message contains a challenge that may be different than the challenge generated by the mediation server as appropriate to the needs and/or requirements of a given implementation. The mobile unit then re-registers using SIP with the appropriate authentication fields filled out accordingly. The SIP proxy then verifies the mobile unit and sends an SIP 200 OK message to effect registration of the mobile unit on the SIP infrastructure.
In a preferred approach, the SIP proxy then transmits a 3Q authorization update request message to the mediation server to indicate the successful authentication of the mobile unit to which the mediation server can respond with a 3Q authentication update response that acknowledges this communication 35. The mediation server and the AAA then conduct a short communication 36 wherein the mediation server sends a RADIUS accounting request (i.e., a “start” request) to the AAA and the AAA responds with a corresponding accounting reply.
Such a series of exchanges will serve to effect a successful registration of a mobile unit notwithstanding the intent and need of the mobile unit to access a non-SIEP-based near-real-time multicast communication service. There will be circumstances and occasions, of course, when such authentication should in fact be unsuccessful (when, for example, the given subscriber is not previously authorized to use such a service or when someone using a cloned mobile unit seeks to gain access to the offered service). For example, and referring momentarily to
Once registered, a given mobile unit may remain registered with the SIP infrastructure for some period of time and may engage in one or more near-real-time multicast communication sessions. At some point it may be desired to deregister the mobile unit from the SIP infrastructure (with such deregistration being either mobile unit initiated or SIP proxy initiated, for example, as appropriate or as desired). With momentary reference to
Such a process will permit an SIP-compatible mobile unit to become authorized to use a near-real-time multicast communication service notwithstanding the use of a RADIUS server that administers such authentication while lacking a native compatibility with session initiation protocol. Optionally, but in a preferred embodiment (and referring again to
When providing billing information regarding a near-real-time multicast communication service, there are a number of useful session parameters that can be used, alone or in combination, to permit a variety of billing possibilities. A number of potential billing criteria were set forth above. Other possibilities also exist, however. For example, when the billing information corresponds to a portion of a near-real-time multicast communication session, that billing information can include one or more of:
With reference to
As already noted, the basic billing information will be captured and retained by the communication service server. The mediation server can use an appropriate data extraction tool or process to access that information. Once obtained, the mediation server can then process the billing information to yield the desired form and substance. The resultant processed billing information can then be forwarded to the AAA for a more final accounting.
As one illustration, and referring now to
Pursuant to these various embodiments, a communication service, such as a near-real-time multicast communication service, can be provided to a given mobile unit with attendant authentication and billing flexibility notwithstanding systemic use of SIP, RADIUS, and file transfer practices in a manner not previously practiced or imagined.
Those skilled in the art will recognize that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the spirit and scope of the invention, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept.
