Hello,
try to keep the mailing list cc-ed -- others may be able to help you
faster or this discussion will be helpful for different people.
The username_spec and password_spec were removed indeed, the first was
useless since the username was taken from auth header and the second
became param
Hello,
the bug was associated with an internal tm function used to send the
request. Can you try again with latest branch 3.1, over the weekend I
backported the fix. Let me know if works now for you.
Thanks,
Daniel
On 9/9/11 3:33 PM, Vitaliy Aleksandrov wrote:
There is a bug in UAC module.
Hello,
you have another group of actions that can send 401 Unauthorized:
if (!check_to()) {
sl_send_reply("401", "Unauthorized");
exit;
}
You can either run with debug=4 and watch the syslog to see some hints
in messag
Hi Juha,
have had any time to try the patch I sent? Thinking of committing it,
but no presence server environment at hand for me to try it quickly...
Thanks,
Daniel
On 9/7/11 6:59 PM, Daniel-Constantin Mierla wrote:
Hello,
On 8/30/11 7:43 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla w
Hello,
On 9/7/11 12:49 AM, David Zambrano wrote:
Ok so
It now includes the record-route but its still not modifying the
contact header and the problem persists.
¿Any suggestions as to how to do that?
for updating the contact header you have to use nathelper module with
fix_natted_contact(). B
Daniel-Constantin Mierla writes:
> have had any time to try the patch I sent? Thinking of committing it,
> but no presence server environment at hand for me to try it quickly...
daniel,
sorry, i forgot about it. is it really a good idea to allow any etag?
would it be better to require that eta
Hello,
On 9/12/11 9:47 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
have had any time to try the patch I sent? Thinking of committing it,
but no presence server environment at hand for me to try it quickly...
daniel,
sorry, i forgot about it. is it really a good idea to allow a
Daniel-Constantin Mierla writes:
> By using ".", the presence server will create a new e-tag, right? It is
> not an update to an existing presence document, but creation of a new
> one.
yes, it is considered a new presence document, which replaces an old one
if any. same as if a single ua crash
Hi,
now I'm using t_flush_flags() after setting the accounting flag in
falure_route and latest updates (I have a new 3.1 clone without depth
parameter and I've made sure your changes are in sources), but it doesn't
solve the case, accounting behavior is still exactly the same as described
in the f
Hello,
On 9/12/11 12:04 PM, Ozren Lapcevic wrote:
Hi,
now I'm using t_flush_flags() after setting the accounting flag in
falure_route and latest updates (I have a new 3.1 clone without depth
parameter and I've made sure your changes are in sources), but it
doesn't solve the case, accounting
Hi,
Thanks Daniel. It work like charm :)
Cheers,
On Thu, Sep 8, 2011 at 10:22 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
>
> On 9/8/11 3:12 AM, MingHon wrote:
>
> Hi,
>
> Sorry, let me explain my situation.
>
> my box is behind nat with private ip 192.168.2.3 and nat ip is 60.x.x.x
>
>
Hello,
Anyone knows if is it possible to use the flags column but not to void
another rule (same carrier and domain id, also same scan_prefix or
empty-value here)?
Thanks,
On Fri, Sep 2, 2011 at 9:52 AM, caio wrote:
> Hello,
>
> The documentation of carrierroute says "If flags and mask are not
Hello,
I was looking into it a bit, looks like an issue in missing flags as
well as received request since it is generated locally. If it is handy
for you, maybe you can send the log messages with debug=4 for a canceled
call. That will help to be sure the right issue is tracked.
Thanks,
Dani
Hello,
just to be sure, you used flag 2 for missed calls, right? I can see it
set in onreply_route.
That means the flags are ok now, the issue seems to be in other place.
You don't set any of the accounting flags in request route block, isn't
it? I mean, the first accounting flag (like accou
14 matches
Mail list logo
