Hey Daniel,
Thanks for your fast reply!
I am using the 4.2.0 out of debian packages (not nightly). Will shift on nightly and retest.
Not a big deal regarding 150 seconds, maybe it should be a good reason for async reloads (reply with the delay number of seconds when reload will happen). Reloads can be always implemented outside of kamailio but since everybody would need it I assume a more centralized approach would be useful.
Anyway, thanks again! DanB
On 24.10.2014 12:00, sr-users-request@lists.sip-router.org wrote:
Hello,
are you using branch 4.2 or some tgz/package from 4.2.0 release? There was a fix related to such issue, so 4.2 branch must be used (or debian nightly builds for 4.2).
I will have to check the code how flexible that is, but afaik, the limit on reload interval was thought to avoid sending again registration requests while retransmissions from previous one can occur.
Cheers, Danel
Hey Daniel,
For the sake of the records, I confirm that the issue with uac.reg_info hanging when executed second time is gone in nightly packages.
Thanks again!
Cheers, DanB
Guys,
I have found that uac.reg_info does not properly filter the records in case of l_uuid being too large (works fine with small number of characters).
Here is the concrete example:
""" root@Dev2:/home/dan# kamcmd -s tcp:127.0.0.1:2046 uac.reg_info l_username 8944538525001446036 root@Dev2:/home/dan# kamcmd -s tcp:127.0.0.1:2046 uac.reg_info l_uuid 8944538525001446036 root@Dev2:/home/dan# kamcmd -s tcp:127.0.0.1:2046 uac.reg_info auth_username 301 { l_uuid: 8944538525001446036 l_username: 8944538525001446036 l_domain: 172.16.254.75 r_username: 301 r_domain: pbx.example.com realm: asterisk auth_username: 301 auth_password: check123 auth_proxy: sip:172.16.254.75 expires: 360 flags: 12 diff_expires: 120 timer_expires: 1414838083 } root@Dev2:/home/dan# kamcmd -s tcp:127.0.0.1:2046 uac.reg_info r_username 301 { l_uuid: 8944538525001446036 l_username: 8944538525001446036 l_domain: 172.16.254.75 r_username: 301 r_domain: pbx.example.com realm: asterisk auth_username: 301 auth_password: check123 auth_proxy: sip:172.16.254.75 expires: 360 flags: 0 diff_expires: 211 timer_expires: 1414838323 } """
Thanks in advance for any kind of tip!
DanB
Hey Guys,
We are facing quite often this error:
/usr/sbin/kamailio[16985]: ERROR: <core> [dset.c:435]: print_dset(): ERROR: redirection buffeROR: redirection buffer length exceed
When the error is generated, there will be a missing contact in the redirects (not to mention that Kamailio will crash in uac_redirect for versions before 4.2.0).
Can anyone explain the nature of this buffer and whether is affected by a single contact or all the contacts together building the final redirect? How can we control what's in that buffer from the script?
This is our script part building the redirects, out of location data: """ if(!reg_fetch_contacts("location", "$ru", "called")) { send_reply("404", "Not Found"); exit; } if $(ulc(called=>count)) == 0 { # No contacts for this user online sl_send_reply("404", "Not found"); exit; } $var(i) = 0; while($var(i) < $(ulc(called=>count))) { $var(pathUri) = $(ulc(called=>path)[$var(i)]{s.strip,1}{s.striptail,1}); #Strip <> so we can apply real uri transformations $var(newRURI) = $(ulc(called=>addr)[$var(i)]) + ";ipbxep=" + $(var(pathUri){uri.host}); if $var(i) == 0 { $ru = $var(newRURI); } else { append_branch($var(newRURI)); } $var(i) = $var(i) + 1; } """
Thanks in advance for any kind of tip!
DanB
Hello,
On 06/11/14 09:38, Dan Christian Bogos wrote:
Hey Guys,
We are facing quite often this error:
/usr/sbin/kamailio[16985]: ERROR: <core> [dset.c:435]: print_dset(): ERROR: redirection buffeROR: redirection buffer length exceed
When the error is generated, there will be a missing contact in the redirects (not to mention that Kamailio will crash in uac_redirect for versions before 4.2.0).
Can anyone explain the nature of this buffer and whether is affected by a single contact or all the contacts together building the final redirect? How can we control what's in that buffer from the script?
This is our script part building the redirects, out of location data: """ if(!reg_fetch_contacts("location", "$ru", "called")) { send_reply("404", "Not Found"); exit; } if $(ulc(called=>count)) == 0 { # No contacts for this user online sl_send_reply("404", "Not found"); exit; } $var(i) = 0; while($var(i) < $(ulc(called=>count))) { $var(pathUri) = $(ulc(called=>path)[$var(i)]{s.strip,1}{s.striptail,1}); #Strip <> so we can apply real uri transformations $var(newRURI) = $(ulc(called=>addr)[$var(i)]) + ";ipbxep=" + $(var(pathUri){uri.host}); if $var(i) == 0 { $ru = $var(newRURI); } else { append_branch($var(newRURI)); } $var(i) = $var(i) + 1; } """
Thanks in advance for any kind of tip!
looks like the overall buffer for contacts in redirect is 512 in size, perhaps same value from early beginnings. MAX_REDIRECTION_LEN in config.h needs to be changed to larger value -- should 1024 be enough?
Cheers, Daniel
Hey Daniel,
Thanks for your fast feedback!
Not sure what is the best approach on this. We reach the 512 limit sometimes even with just 2 contacts in one AOR (since we cannot pass the path in redirect, we use a uri parameter to add it and process that later in other components, so I guess that is our sin). I guess we can work with 1024 as well, but on the other hand, how can I control what goes into that buffer?
Will counting in the script of the RURIs length in all of the branches before calling 302 be sufficient to keep the buffer under it's limits? Would it be not possible for the core to check on each contact if adding it will not create the buffer overflow instead of dropping all data in the buffer (returning no contact) when that happens? The issue is that it is hard for me as admin to know what will go into the contact data since that content comes directly from UAs.
Cheers, DanB
looks like the overall buffer for contacts in redirect is 512 in size, perhaps same value from early beginnings. MAX_REDIRECTION_LEN in config.h needs to be changed to larger value -- should 1024 be enough?
Cheers, Daniel
Hello,
trying to count in the config could be a way, but I guess you have to add some delimiter overhead between contacts.
Increasing it was a proposal for a lazy solution that can be easily backported. A proper way can be via dynamic allocation or making the size configurable via a param.
The code does check if adding a new contact results in overflow, but then returns an error and the old used contacts are not considered.
Cheers, Daniel
On 06/11/14 11:35, Dan Christian Bogos wrote:
Hey Daniel,
Thanks for your fast feedback!
Not sure what is the best approach on this. We reach the 512 limit sometimes even with just 2 contacts in one AOR (since we cannot pass the path in redirect, we use a uri parameter to add it and process that later in other components, so I guess that is our sin). I guess we can work with 1024 as well, but on the other hand, how can I control what goes into that buffer?
Will counting in the script of the RURIs length in all of the branches before calling 302 be sufficient to keep the buffer under it's limits? Would it be not possible for the core to check on each contact if adding it will not create the buffer overflow instead of dropping all data in the buffer (returning no contact) when that happens? The issue is that it is hard for me as admin to know what will go into the contact data since that content comes directly from UAs.
Cheers, DanB
looks like the overall buffer for contacts in redirect is 512 in size, perhaps same value from early beginnings. MAX_REDIRECTION_LEN in config.h needs to be changed to larger value -- should 1024 be enough?
Cheers, Daniel
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
Hey Daniel,
OK, in that case if not too much trouble, please increase the buffer size to 1024 and I will try to manage it also in the script.
Thanks again! DanB
-
Dan Christian Bogos -
Daniel-Constantin Mierla