Hi
We have found that in kamailio processing if you: 1. set msg->path_vec 2. call msg_apply_changes() 3. t_telay
The route-header of the outgoing message is set twice.
We think this is because msg_apply_changes() adds the router header if the path is set - but leaves the path set. So the router header is added again when you t_relay.
To fix this: --- a/modules/textopsx/textopsx.c +++ b/modules/textopsx/textopsx.c @@ -166,7 +166,7 @@ static int msg_apply_changes_f(sip_msg_t *msg, char *str1, char *str2) } else { obuf.s = build_req_buf_from_sip_req(msg, (unsigned int*)&obuf.len, &dst, - BUILD_NO_LOCAL_VIA|BUILD_NO_VIA1_UPDATE); + BUILD_NO_PATH|BUILD_NO_LOCAL_VIA|BUILD_NO_VIA1_UPDATE); } if(obuf.s == NULL) {
This stops msg_apply_changes() from adding the router header if path is set.
Any objections to comitting this to master? Might other functionality be effected?
The alternative is for msg_apply_changes() to add the router header but then unset the path.
Regards Richard.
Hi Devs,
Any comment/problem with this change? If not, I'd like to commit this week. Seem fine to me.
Cheers Jason
On Fri, Mar 7, 2014 at 5:41 PM, Richard Good richard.good@smilecoms.comwrote:
Hi
We have found that in kamailio processing if you:
- set msg->path_vec
- call msg_apply_changes()
- t_telay
The route-header of the outgoing message is set twice.
We think this is because msg_apply_changes() adds the router header if the path is set - but leaves the path set. So the router header is added again when you t_relay.
To fix this: --- a/modules/textopsx/textopsx.c +++ b/modules/textopsx/textopsx.c @@ -166,7 +166,7 @@ static int msg_apply_changes_f(sip_msg_t *msg, char *str1, char *str2) } else { obuf.s = build_req_buf_from_sip_req(msg, (unsigned int*)&obuf.len, &dst,
BUILD_NO_LOCAL_VIA|BUILD_NO_VIA1_UPDATE);
BUILD_NO_PATH|BUILD_NO_LOCAL_VIA|BUILD_NO_VIA1_UPDATE); } if(obuf.s == NULL) {
This stops msg_apply_changes() from adding the router header if path is set.
Any objections to comitting this to master? Might other functionality be effected?
The alternative is for msg_apply_changes() to add the router header but then unset the path.
Regards Richard.
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/ http://www.smilecoms.com/disclaimer
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
it can be committed, indeed.
Cheers, Daniel
On 09/03/14 17:01, Jason Penton wrote:
Hi Devs,
Any comment/problem with this change? If not, I'd like to commit this week. Seem fine to me.
Cheers Jason
On Fri, Mar 7, 2014 at 5:41 PM, Richard Good <richard.good@smilecoms.com mailto:richard.good@smilecoms.com> wrote:
Hi We have found that in kamailio processing if you: 1. set msg->path_vec 2. call msg_apply_changes() 3. t_telay The route-header of the outgoing message is set twice. We think this is because msg_apply_changes() adds the router header if the path is set - but leaves the path set. So the router header is added again when you t_relay. To fix this: --- a/modules/textopsx/textopsx.c +++ b/modules/textopsx/textopsx.c @@ -166,7 +166,7 @@ static int msg_apply_changes_f(sip_msg_t *msg, char *str1, char *str2) } else { obuf.s = build_req_buf_from_sip_req(msg, (unsigned int*)&obuf.len, &dst, - BUILD_NO_LOCAL_VIA|BUILD_NO_VIA1_UPDATE); + BUILD_NO_PATH|BUILD_NO_LOCAL_VIA|BUILD_NO_VIA1_UPDATE); } if(obuf.s == NULL) { This stops msg_apply_changes() from adding the router header if path is set. Any objections to comitting this to master? Might other functionality be effected? The alternative is for msg_apply_changes() to add the router header but then unset the path. Regards Richard. This email is subject to the disclaimer of Smile Communications athttp://www.smilecoms.com/home/email-disclaimer/ _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev--
*Jason Penton* *Senior Manager: Applications and Services* *Smile Communications Pty (Ltd)* *Mobile:* +27 (0) 83 283 7000 *Skype:* jason.barry.penton
jason.penton@smilecoms.com mailto:name.surname@smilecoms.com www.smilecoms.com http://www.smilecoms.com/
This email is subject to the disclaimer of Smile Communications athttp://www.smilecoms.com/home/email-disclaimer/ http://www.smilecoms.com/home/email-disclaimer/
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Daniel-Constantin Mierla -
Jason Penton -
Richard Good