Re: [Dime] one doubt about sip application
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dime] one doubt about sip application



Glen Zorn (gwz) wrote:
> Miguel Garcia <mailto:Miguel.An.Garcia at nokia.com> supposedly scribbled:
> 
>> Tony:
>>
>> The intention of the SIP-Accounting-Information is to outsource
>> Diameter accounting to a different server, not to a different realm.
>> So, from that point of view, the idea is to keep the realm constant,
>> but not the server. I am not sure of any use case where you need to
>> switch realms within the same application (SIP services), but
>> different hosts (authorization/authentication vs. accounting).     
>>
>> Additionally, if the Diameter client gets only the realm where to
>> provide accounting, as you propose, then you need to have a mechanism
>> to guarantee that you can discover the host out of the realm. So, if
>> this mechanism is not in place, or the Realm Routing Table is not
>> properly provisioned, you run into trouble.    
> 
> What happens if the provided host crashes?  Do you just throw awa the accounting message?

No, you are supposed to install several servers for redundancy purposes,
so there is a backup accounting server. The SIP-Accounting-Information
AVP allows for repetition of the URI of each server, so you can provide
as many as you want:

      SIP-Accounting-Information ::= < AVP Header: xx01 >
                                   * [ SIP-Accounting-Server-URI ]
                                   * [ SIP-Credit-Control-Server-URI ]
                                   * [ AVP]


Additionally, you can also get redundancy through round robin DNS,
although I favor the repetition of the URI AVPs.

/Miguel


-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia at openlaboratory.net
Nokia Research Center      Helsinki, Finland


_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.