Hi, Im sorry, yet again. You are abseloutly right. I was switching between SER and OpenSER (and of-cource two separate databases) on the same plattform, and it turned out that the timers generated a 408 right after I declined the call. I did not realize that I had one more contact in usrloc aswell. Hence, the 603 was absorbed correctly and a 408 generated for the second contact..

...much ado about nothing...sorry about that.

best regards, hw

On Thu, 2005-09-08 at 00:44 +0200, Klaus Darilion wrote:

is the 408 immediately sent after the 603 or after a timeout? Maybe there was another branch which timed out.

klaus

Helge Waastad wrote:

...

Sorry, not 403, but 408......it's a litle bit late right now.....at least for me...

---

Subject: 603 to 403 From: Helge Waastad helge@smartnet.no Date: Wed, 07 Sep 2005 22:23:19 +0200 To: users@openser.org

To: users@openser.org

Hi, I noticed that when a client declines a call (603) it is forwarded out as an 403 from openser....I belive this is something that was fixed in the SER-0.9.4....(?)

---

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Hi Gustavo,

thanks for report - hopefully it's fixed now on cvs.

regards, bogdan

Gustavo García wrote:

Hi,

There are a core dump when using uac_auth with from_restore_mode = none.

I think the problem is this:

If from_restore_mode is NONE the load_tm_api isn't called in init function (file uac.c).

load_tm_api(&uac_tmb)

When uac_auth is used it invokes uac_tmb.t_gett that isn't set (file auth.c).

t = uac_tmb.t_gett();

BR.

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users