[Users] ENUM behaviour issue

[Klaus Darilion]

Bogdan-Andrei Iancu wrote:
> Hi there,
> 
> so, without messing with the order/priority of the records, we can go 
> for the following options:
>    1) fork or not - use only first record (according to priority) or use 
> all of them;
>    2) if fork - what kind of fork: serial or parallel (both respecting 
> the priorities)

I prefer the second one. the highest prior URI should go into the 
current branch, and the other URIs should go into AVPs ordered by 
priority (like load_contacts from lcr module).

Then, serial forking can be implemented in the routing logic.

regards,
klaus


> does everybody agree with this frame?
> 
> regards,
> Bogdan
> 
> 
> Klaus Darilion wrote:
> 
>> Juha Heinanen wrote:
>>
>>> Daniel-Constantin Mierla writes:
>>>
>>>  > Maybe you can shed some light regarding the priority, what is it 
>>> good  > for in enum case, how it should be used? In this way, can be 
>>> decided if  > worth to implement these features. I have other things 
>>> in my todo list  > in the next days, so I do not want to waste time 
>>> at all.
>>>
>>> the owner of enum record may have decided that he wants to be first
>>> contacted at a given uri and, if that fails, at another one, or more
>>> than one uris simultaneously, etc.  for that purpose enum NAPTR record
>>> contains two fields, order and preference:
>>>
>> ...
>>
>>> in my opinion, sip proxy should obey the wish of the enum record owner
>>> as specified by these two fields.   it is the same as with q values of
>>> registered contacts.  proxy should not mess around with them.
>>
>>
>>
>> I agree. Thus, we need serial forking (like in LCR module with AVPs), 
>> not parallel forking (current behaviour).
>>
>> regards,
>> klaus
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
> 
>