RE: : Target Diameter server poorly specified

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

...

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

Actually, the clarification and summary that you gave above was quite helpful; I think that it would be very useful to incorporate it in the informational portion of the document.  The other change you mention is fine, of course.

...

Hope this helps,

~gwz

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