Re: : Target Diameter server poorly specified

Hi Glen:

Your proposal sounds reasonable. I will add the summary that I wrote to 
Section 5.1, which is supposed to described the general architecture. I 
hope this will give a better understanding to the reader.

I will be submitting a new version for publication today. I don't want 
to miss the deadline.

Regards,

         Miguel

Glen Zorn (gwz) wrote:

> 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

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