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:
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
On 1/7/11 3:32 PM, Stefan Prelle wrote:
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:
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
-
Daniel-Constantin Mierla -
Stefan Prelle