Hi folks,
Since upgrading vom Kamailio 1.5 to 3.1 I have a problem using get_redirects from the uac_redirect module. It seems that there is a problem with parsing the Contact header from the received 302.
This is my script excerpt: if (t_check_status("3[0-9][0-9]")) { get_redirects("*"); if (!t_relay()) { xlog("L_ERR","t_relay failed\n"); } }
Some 302 messages lead (as expected) to INVITEs send to targets in the Contact header, for others t_relay fails.
A working example would be Contact:sip:+49406686100@192.168.0.1:5060;user=phone;q=0.5,sip: +49406686100@192.168.0.2:5060;user=phone;q=0.25
It fails on Contact: sip:+49406686100@192.168.0.1:5060
The following log messages appear when calling get_redirects (and failing t_relay):
kamailio[7372]: DEBUG: uac_redirect [rd_funcs.c:74]: resume branch=0 kamailio[7372]: DEBUG: uac_redirect [rd_funcs.c:81]: checking branch=0 (added=0) kamailio[7372]: DEBUG: uac_redirect [rd_funcs.c:85]: branch=0 is a redirect (added=0) kamailio[7372]: WARNING: <core> [mem/q_malloc.c:366]: qm_malloc(0x82ba320, 32) called from <core>: parser/msg_parser.c: parse_headers(339) kamailio[7372]: WARNING: <core> [mem/q_malloc.c:406]: qm_malloc(0x82ba320, 32) returns address 0x8311d94 frag. 0x8311d7c (size=32) on 1 -th hit kamailio[7372]: DEBUG: uac_redirect [rd_funcs.c:233]: contact hdr not found in sh_rpl
The Contact header that fails obviously has no parameters for the URI and contact itself. As far as I understand the RFC 3261 BNF this is valid. The 302 response is by the way created by kamailio when using the LCR module (like this) if (!load_gws("1")) {... exit;} if (!next_gw()) {... exit; } sl_send_reply("302", "Not here");
Did I miss anything when upgrading or is this a problem with the parser?
Cheers, Stefan
Hello,
On 1/7/11 1:55 PM, Stefan Prelle wrote:
Hi folks,
Since upgrading vom Kamailio 1.5 to 3.1 I have a problem using get_redirects from the uac_redirect module. It seems that there is a problem with parsing the Contact header from the received 302.
This is my script excerpt: if (t_check_status("3[0-9][0-9]")) { get_redirects("*"); if (!t_relay()) { xlog("L_ERR","t_relay failed\n"); } }
Some 302 messages lead (as expected) to INVITEs send to targets in the Contact header, for others t_relay fails.
A working example would be Contact:sip:+49406686100@192.168.0.1:5060;user=phone;q=0.5,sip: +49406686100@192.168.0.2:5060;user=phone;q=0.25
It fails on Contact: sip:+49406686100@192.168.0.1:5060
The following log messages appear when calling get_redirects (and failing t_relay):
kamailio[7372]: DEBUG: uac_redirect [rd_funcs.c:74]: resume branch=0 kamailio[7372]: DEBUG: uac_redirect [rd_funcs.c:81]: checking branch=0 (added=0) kamailio[7372]: DEBUG: uac_redirect [rd_funcs.c:85]: branch=0 is a redirect (added=0) kamailio[7372]: WARNING:<core> [mem/q_malloc.c:366]: qm_malloc(0x82ba320, 32) called from<core>: parser/msg_parser.c: parse_headers(339) kamailio[7372]: WARNING:<core> [mem/q_malloc.c:406]: qm_malloc(0x82ba320, 32) returns address 0x8311d94 frag. 0x8311d7c (size=32) on 1 -th hit kamailio[7372]: DEBUG: uac_redirect [rd_funcs.c:233]: contact hdr not found in sh_rpl
The Contact header that fails obviously has no parameters for the URI and contact itself. As far as I understand the RFC 3261 BNF this is valid.
yes, the contact is valid. Can you place an xlog like:
xlog("=== contact header: $T_rpl($ct)\n");
in failure route and see if the contact header body is printed? You need tmx module loaded.
Cheers, Daniel
The 302 response is by the way created by kamailio when using the LCR module (like this) if (!load_gws("1")) {... exit;} if (!next_gw()) {... exit; } sl_send_reply("302", "Not here");
Did I miss anything when upgrading or is this a problem with the parser?
Cheers, Stefan
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel,
Am Freitag, den 07.01.2011, 14:13 +0100 schrieb Daniel-Constantin Mierla:
yes, the contact is valid. Can you place an xlog like:
xlog("=== contact header: $T_rpl($ct)\n");
in failure route and see if the contact header body is printed? You need tmx module loaded.
The log contains now kamailio[8624]: ERROR: <script>: === contact header: sip: +49406686100@192.168.0.1:5060
Stefan
On 1/7/11 3:32 PM, Stefan Prelle wrote:
Hi Daniel,
Am Freitag, den 07.01.2011, 14:13 +0100 schrieb Daniel-Constantin Mierla:
yes, the contact is valid. Can you place an xlog like:
xlog("=== contact header: $T_rpl($ct)\n");
in failure route and see if the contact header body is printed? You need tmx module loaded.
The log contains now kamailio[8624]: ERROR:<script>: === contact header: sip: +49406686100@192.168.0.1:5060
so the contact header is seen by the parser, I will check the uac module to see if there is something wrong.
Cheers, Daniel
On 1/7/11 8:10 PM, Daniel-Constantin Mierla wrote:
On 1/7/11 3:32 PM, Stefan Prelle wrote:
Hi Daniel,
Am Freitag, den 07.01.2011, 14:13 +0100 schrieb Daniel-Constantin Mierla:
yes, the contact is valid. Can you place an xlog like:
xlog("=== contact header: $T_rpl($ct)\n");
in failure route and see if the contact header body is printed? You need tmx module loaded.
The log contains now kamailio[8624]: ERROR:<script>: === contact header: sip: +49406686100@192.168.0.1:5060
so the contact header is seen by the parser, I will check the uac module to see if there is something wrong.
I found and fixed an issue that should solved. However, that is also present in version 1.5, but I guess you have a different config where the contact header was parsed before getting to get_redirects().
Specifically, the issue was related to the fact that inside get_redirects() the parser was invoked with the contact header type instead of appropriate flag, so no search for contact header was actually done.
Can you try latest 3.1 and tell if works ok. If yes, I will port back to 1.5 as well.
Thanks, Daniel
Hi Daniel,
Am Freitag, den 07.01.2011, 23:54 +0100 schrieb Daniel-Constantin Mierla:
I found and fixed an issue that should solved. However, that is also present in version 1.5, but I guess you have a different config where the contact header was parsed before getting to get_redirects().
Glad to hear that.
Specifically, the issue was related to the fact that inside get_redirects() the parser was invoked with the contact header type instead of appropriate flag, so no search for contact header was actually done.
Can you try latest 3.1 and tell if works ok. If yes, I will port back to 1.5 as well.
It is working now. Thanks for your quick response and fix.
Cheers, Stefan
-
Daniel-Constantin Mierla -
Stefan Prelle