RE: : Target Diameter server poorly specified

Miguel Garcia <mailto:[email protected]> supposedly scribbled:

...

>>> It is correct to think that there is a single Diameter server (for a
>>> given user).
>> 
>> 
>> No, that can't be so: there must be only one Diameter server
>> _period_ for this to work, unless the entire farm is preconfigured
>> to know which Diameter handles requests for any given user.  If the
>> Diameter clients can send requests to more than one server, how do
>> they know which one handled the previous request (and thus holds the
>> necessary state)?  What am I missing here?     
> 
> So... let me clarify the situation:
> 
> On one side, we say that ***for a given user*** his data is stored in
> a single Diameter server. We say that such Diameter server can be
> configured as a farm of redundant servers, something that is outside
> the scope of this specification. In this case it is required that all
> the servers in the farm keep the data synchronized, again, something
> that is not within the scope of this specification.  

The farm to which I was referring is the "Diameter client/SIP Server 1" farm.  You say that the second request can go to any Diameter Client/SIP Server 1, but it needs data from the first request which is only held on one Diameter server (whether that server is virtual or not seems irrelevant), the Diameter server that handled the first request.  The question is, how does the Diameter client know how to correctly route the second REGISTER message?
 
...

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel