Hi Juha!
I tried your new add_contact_alias function - some questions:
1.
+ /* Compare source ip and port against contact uri */ + if ((ip = str2ip(&(uri.host))) == NULL) { + LM_ERR("contact uri host is not an ip address\n"); + return -1; + }
Why do you in return -1 in case of a domain instead of adding the alias parameter in this case too?
2. AFAIS the new functions are included in sr3.0 branch, but not in kamailio-3.0 branch. Why?
regards klaus
Klaus Darilion writes:
- /* Compare source ip and port against contact uri */
- if ((ip = str2ip(&(uri.host))) == NULL) {
LM_ERR("contact uri host is not an ip address\n");return -1;- }
Why do you in return -1 in case of a domain instead of adding the alias parameter in this case too?
that is because of the current definition of add_contact_alias():
6.14. add_contact_alias()
Adds ;alias=ip:port parameter to contact URI containing received ip:port if contact uri ip:port does not match received ip:port.
- AFAIS the new functions are included in sr3.0 branch, but not in
kamailio-3.0 branch. Why?
current practice seem to be that if someone needs something from the other branch (k or sr), then he/she needs to sherry pick the commits from the other branch.
-- juha
Hi Juha!
handle_ruri_alias() does not work if the alias parameter is not the first parameter. As changing the order of parameters is allowed maybe this should be handled correctly.
regards klaus
On 22.12.2009 18:13, Juha Heinanen wrote:
Klaus Darilion writes:
- /* Compare source ip and port against contact uri */
- if ((ip = str2ip(&(uri.host))) == NULL) {
LM_ERR("contact uri host is not an ip address\n");return -1;- }
Why do you in return -1 in case of a domain instead of adding the alias parameter in this case too?
that is because of the current definition of add_contact_alias():
6.14. add_contact_alias()
Adds ;alias=ip:port parameter to contact URI containing received ip:port if contact uri ip:port does not match received ip:port.
- AFAIS the new functions are included in sr3.0 branch, but not in
kamailio-3.0 branch. Why?
current practice seem to be that if someone needs something from the other branch (k or sr), then he/she needs to sherry pick the commits from the other branch.
-- juha
Klaus Darilion writes:
handle_ruri_alias() does not work if the alias parameter is not the first parameter. As changing the order of parameters is allowed maybe this should be handled correctly.
yes, it needs to stay as first parameter. i implemented it that way because of simplicity. i would first like to see a real use case where the params get reordered before starting to spend more cycles on it.
-- juha
On 23.12.2009 15:56, Juha Heinanen wrote:
Klaus Darilion writes:
handle_ruri_alias() does not work if the alias parameter is not the first parameter. As changing the order of parameters is allowed maybe this should be handled correctly.
yes, it needs to stay as first parameter. i implemented it that way because of simplicity. i would first like to see a real use case where the params get reordered before starting to spend more cycles on it.
Actually I use it together with encode_contact/decode_contact functions (siputils) which changes the order of URI parameters.
regards klaus
On 23.12.2009 16:26, Juha Heinanen wrote:
Klaus Darilion writes:
Actually I use it together with encode_contact/decode_contact functions (siputils) which changes the order of URI parameters.
may be it would help if you changed the order in which you call those.
You are lucky - that solved my problem ;-)
thanks klaus
by the way, there was a bug in my original alias usage instructions: add_contact_alias() needs to be called also on in-dialog requests from UAs.
-- juha
-
jh＠tutpro.com -
Klaus Darilion