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