30 Oct
2007
30 Oct
'07
10:57 a.m.
El Tuesday 30 October 2007 10:28:36 Bogdan-Andrei Iancu escribió:
But why do you need to keep the timeout in the
location table? keep it
in avp table or in the subscriber table.
I don't understand how can be useful a timeout value in subscriber table. If a
subscriber calls it will hangup when he decides, why to force it?
I use LCR for call before users with greater "q".
And I insert entries in "location" table via web app to implement forwarding
(depending on the "q" value it can be serial or parallel).
So I need a INVITE timeout for each forwarding but not for each subscriber
user.
For example:
"location" table:
-----------------------------------------------------------------------------------------------------
username domain contact q timeout
200 domain.org sip:200@10.10.1.33:5060 0.50 null
200 domain.org sip:215@domain.org 0.40 20
200 domain.org sip:66612323@domain.org 0.30 60
200 domain.org sip:65532090@domain.org 0.30 60
-----------------------------------------------------------------------------------------------------
When 200(a)domain.org is called "next_contacts()"
returns "sip:200@10.10.1.33:5060" (the "real" registered user) so
it's valid
the parameter "fr_inv_timer_next" of "lcr" module.
If it doesn't answer, failure_route calls to sip:215@domain.org. The timeout
would be "lcr" - "fr_inv_timer_next" by default, but I'd like this
to be
customizable per entry in "location" table:
During "lookup(location)" "timeout" field should be loaded
as "fr_inv_timer_avp".
For this I'd need a way to load that value when doing "lookup()".
That is why it'd be cool this feature in my case.
Regards.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es