Re: : Target Diameter server poorly specified

Glen Zorn (gwz) wrote:

> 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?

So we were speaking about different stuff.... so, forget about our 
previous discussion.

Yes, there can be a number (farm) of "Diameter client/SIP server 1", due 
to configuration in DNS through NAPTR/SRV records. Therefore, if we 
refer for example to Figure 2 in Section 5.3, there is no guarantee that 
the REGISTER #1 and #9 are received at the same SIP server. However, 
both REGISTER requests have to be routed to the same SIP server 2, so 
that REGISTER #4 and #12 are received at the same SIP server.

To solve this problem, the MAR message #5 records the SIP URI of SIP 
server 2 in the Diameter server. Later, when SIP server 1 (potentially 
another SIP server 1 in a farm) queries the Diameter server with UAR 
#10, the Diameter server returns in UAA #11 the stored URI of SIP server 2.

So... to clarify and summarize.

- Diameter server: there is one. For redundancy there could be more than 
one but all of them have keep the data synchronized.

- SIP server 1: there is a farm, typically configured through DNS 
NAPTR/SRV records that point to diffent boxes. There is no requirement 
for these types of server to keep state.

- SIP server 2: ther are a few of them, but once the user registers for 
the first time, one is selected, allocated, and all the request should 
be processed by the same SIP server (of course, there can be redundancy 
as well, if the data is kept synchronized).

As for your original post, I agree in change the "a" with an "the":

OLD:
The Diameter client in SIP server 1 contacts a Diameter server by 
sending a Diameter UAR message (step 10) to determine the SIP server 
allocated to the user.

NEW:
The Diameter client in SIP server 1 contacts the Diameter server by 
sending a Diameter UAR message (step 10) to determine the SIP server 
allocated to the user.


I hope this solves this issue.

/Miguel


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

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email protected]
Nokia Research Center      Helsinki, Finland