Hi!
Currently, the ENUM module appends branches for every found NAPTR. E.g. if I have
0.0.2.1.1.8.0.8.7.3.4.e164.arpa 1 NAPTR 100 10 "u" "e2u+SiP" "!^.*$!sip:15990@fwd.pulver.com!" . 1 NAPTR 200 10 "u" "e2u+SiP" "!^.*$!sip:klaus3000@iptel.org!" .
openser will use parralell forking. Is it possible to turn on/off this behaviour?
I would prefer for example if the ENUM module would put the highest prior URI into the current branch, and the other found URIs into an AVP. Thus, it is possible to decide between, serial forking, parallel forking or no forking at all.
regards, klaus
Hello,
On 08/05/05 14:22, Klaus Darilion wrote:
Hi!
Currently, the ENUM module appends branches for every found NAPTR. E.g. if I have
0.0.2.1.1.8.0.8.7.3.4.e164.arpa 1 NAPTR 100 10 "u" "e2u+SiP" "!^.*$!sip:15990@fwd.pulver.com!" . 1 NAPTR 200 10 "u" "e2u+SiP" "!^.*$!sip:klaus3000@iptel.org!" .
openser will use parralell forking. Is it possible to turn on/off this behaviour?
I would prefer for example if the ENUM module would put the highest prior URI into the current branch, and the other found URIs into an AVP. Thus, it is possible to decide between, serial forking, parallel forking or no forking at all.
not without development, but I would love to have these options. Never took a deep look at enum module, but adding AVPs is not at all a big deal. I will try to make a patch, if no one else volunteers.
Should these new characteristics be enabled/disabled via module parameter or via functions/function parameters?
Daniel
regards, klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Daniel-Constantin Mierla wrote:
Hello,
On 08/05/05 14:22, Klaus Darilion wrote:
Hi!
Currently, the ENUM module appends branches for every found NAPTR. E.g. if I have
0.0.2.1.1.8.0.8.7.3.4.e164.arpa 1 NAPTR 100 10 "u" "e2u+SiP" "!^.*$!sip:15990@fwd.pulver.com!" . 1 NAPTR 200 10 "u" "e2u+SiP" "!^.*$!sip:klaus3000@iptel.org!" .
openser will use parralell forking. Is it possible to turn on/off this behaviour?
I would prefer for example if the ENUM module would put the highest prior URI into the current branch, and the other found URIs into an AVP. Thus, it is possible to decide between, serial forking, parallel forking or no forking at all.
not without development, but I would love to have these options. Never took a deep look at enum module, but adding AVPs is not at all a big deal. I will try to make a patch, if no one else volunteers.
That would be great.
Should these new characteristics be enabled/disabled via module parameter or via functions/function parameters?
I have no preferences, both would be ok. If it is a function parameter, it should work with all available enum-function calls.
regards klaus
Daniel
regards, klaus
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Daniel-Constantin Mierla writes:
not without development, but I would love to have these options. Never took a deep look at enum module, but adding AVPs is not at all a big deal. I will try to make a patch, if no one else volunteers.
if you do these kind of modifications, please don't do it at the expense of performance of current, standards compliant operation of the module.
just for curiosity, can you override the behavior of your email client so that it doesn't obey the priority of MX records? if not, why would it be necessary for enum records?
-- juha
On 08/05/05 22:48, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
not without development, but I would love to have these options. Never took a deep look at enum module, but adding AVPs is not at all a big deal. I will try to make a patch, if no one else volunteers.
if you do these kind of modifications, please don't do it at the expense of performance of current, standards compliant operation of the module.
I have to admit that I didn't read the specifications, but it is quite logic to me to do serial forking if the records have different priority. No intention to alter the performance, if it is necessary, new methods should be implemented (as I said in my previous mail, I have not much inside knowledge about the enum module).
just for curiosity, can you override the behavior of your email client so that it doesn't obey the priority of MX records?
Never needed, never tried :-).
if not, why would it be necessary for enum records?
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.
Daniel
-- juha
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:
Order A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed to ensure the correct ordering of rules. Low numbers are processed before high numbers, and once a NAPTR is found whose rule "matches" the target, the client MUST NOT consider any NAPTRs with a higher value for order (except as noted below for the Flags field).
Preference A 16-bit unsigned integer that specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. A client MAY look at records with higher preference values if it has a good reason to do so such as not understanding the preferred protocol or service.
The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences. I.e., Preference is used to give weight to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint.
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.
-- juha
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
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)
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
Hi there,
so, without messing with the order/priority of the records, we can go for the following options:
- 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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu wrote:
Hi there,
so, without messing with the order/priority of the records, we can go for the following options:
- 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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Bogdan-Andrei Iancu writes:
1) fork or not - use only first record (according to priority) oruse all of them;
using only the highest priority record might make sense if1 you know that you want to speak with the highest priority destination and, if that is not available, give up. but it may be hard to know when this is the case and therefore i don't see it practical.
2) if fork - what kind of fork: serial or parallel (both respectingthe priorities)
this (and also case 1) is already supported by lcr module.
-- juha
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
not without development, but I would love to have these options. Never took a deep look at enum module, but adding AVPs is not at all a big deal. I will try to make a patch, if no one else volunteers.
if you do these kind of modifications, please don't do it at the expense of performance of current, standards compliant operation of the module.
Can you point me to the standard which says: multiple records = parallel forking?
just for curiosity, can you override the behavior of your email client so that it doesn't obey the priority of MX records? if not, why would it be necessary for enum records?
I've never heard about forked emails...
klaus
Klaus Darilion writes:
Can you point me to the standard which says: multiple records = parallel forking?
enum module has nothing to do with parallel or sequential forking. it simply sets q value of contacts based on parameter values in naptr records. you can then specify in your ser.cfg how you want forking to be done.
-- juha
Juha Heinanen wrote:
Klaus Darilion writes:
Can you point me to the standard which says: multiple records = parallel forking?
enum module has nothing to do with parallel or sequential forking. it simply sets q value of contacts based on parameter values in naptr records. you can then specify in your ser.cfg how you want forking to be done.
Sorry for my ignorance, but how do I specify serial forking?
klaus
I didn't knew that load_contacts clears all branches - now things are much clearer.
For the files: enum_query(); # load all sip NAPTRs into the current branches and # set q value according to NAPTR priority load_contacs(); # load current branches into AVPs considering q values # and clear all existing branches next_contacts();# create branch(es) with highest prior AVP(s)
t_relay();
Now, only the highest prior NAPTR(s) is in the branch.
regards, klaus
Juha Heinanen wrote:
Klaus Darilion writes:
Sorry for my ignorance, but how do I specify serial forking?
see load_contacts/next_contacts documentation of lcr module.
-- juha
On 08/12/05 19:59, Klaus Darilion wrote:
I didn't knew that load_contacts clears all branches - now things are much clearer.
Neither do I. It is in the todo list to add proper serial forking (based on q) to tm or core -- maybe reusing/moving next_contacts() could be an option now and update usrloc/registrar to set the proper list of avps when doing lookup ...
Daniel
For the files: enum_query(); # load all sip NAPTRs into the current branches and # set q value according to NAPTR priority load_contacs(); # load current branches into AVPs considering q values # and clear all existing branches next_contacts();# create branch(es) with highest prior AVP(s)
t_relay();
Now, only the highest prior NAPTR(s) is in the branch.
regards, klaus
Juha Heinanen wrote:
Klaus Darilion writes:
Sorry for my ignorance, but how do I specify serial forking?
see load_contacts/next_contacts documentation of lcr module.
-- juha
Daniel-Constantin Mierla writes:
Neither do I. It is in the todo list to add proper serial forking (based on q) to tm or core -- maybe reusing/moving next_contacts() could be an option now and update usrloc/registrar to set the proper list of avps when doing lookup ...
i implemented load_contacts/next_contacts functions because native serial forking by tm module didn't exist and touching tm module code myself was out of question.
a tm based implementation of serial forking makes sense provided that it gives some real added value as compared to existing load_contacts/next_contacts implementation. if not, i would suggest using the development cycles to implement something that doesn't currently exist.
-- juha
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
a tm based implementation of serial forking makes sense provided that it gives some real added value as compared to existing load_contacts/next_contacts implementation. if not, i would suggest using the development cycles to implement something that doesn't currently exist.
I agree.
klaus
-
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Juha Heinanen -
Klaus Darilion