15 Feb
2005
15 Feb
'05
11:49 a.m.
Hi,
I have in my ser.cfg:
modparam("tm","fr_inv_timer",40)
set as a timer so that INVITEs coming from PSTN callers go to
voicemail after 40 seconds. This works great for inbound called,
however it seems to be a limitation for outbound calls. If the
outbound INVITE doesn't receive an ACK in that time period, the call
gets cancelled and drops to fast busy.
Is there a way around this? Can I set different timers for inbound and
outbound calls? 40 seconds seems to be a good amount time so that
most outbound calls get answered by voicemail or actual people, but
occastionally users will still get a fast busy.
Any advice is greatly appreciated.
Dan
15 Feb
15 Feb
11:53 a.m.
Depends upon the version. I'm using 0.8.14 stable. In there the answer
is no or not really. You can build another proxy and use one for inbound
and one for outbound calling. This way the same timer can have different
values thereby producing different results for inbound and outbound
calls.
I understand some people have had success on this issue with avp_ops
module in 0.9.0 but I have yet to address this issue in that release.
-Steve
Daniel Poulsen wrote:
Hi,
I have in my ser.cfg:
modparam("tm","fr_inv_timer",40)
set as a timer so that INVITEs coming from PSTN callers go to
voicemail after 40 seconds. This works great for inbound called,
however it seems to be a limitation for outbound calls. If the
outbound INVITE doesn't receive an ACK in that time period, the call
gets cancelled and drops to fast busy.
Is there a way around this? Can I set different timers for inbound and
outbound calls? 40 seconds seems to be a good amount time so that
most outbound calls get answered by voicemail or actual people, but
occastionally users will still get a fast busy.
Any advice is greatly appreciated.
Dan
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@upenn.edu
5:38 p.m.
On 15-02 11:53, Steve Blair wrote:
I understand some people have had success on this
issue with avp_ops
module in 0.9.0 but I have yet to address this issue in that release.
That's correct, in 0.9.0 you can set different timer values on per
transaction basis. TM module would pick the value for the timers from
AVPs, see fr_timer_avp and fr_inv_timer_avp parameters of tm module.
The AVPs can be loaded using avp or avpsops modules.
Note that there is a performance inpact when this feature is used, but
in real world setups it does not seem to harm.
Jan.
16 Mar
16 Mar
6:14 p.m.
I am finally at the point where I am trying this with 0.9.0 and I have
just a couple of questions.
Jan, you state that tm will "pick up" the timers from AVP. I've
seached the list and find references to fr_inv_timer_avp that look
like this:
modparam("tm", "fr_timer", 15)
modparam("tm", "fr_inv_timer", 22)
modparam("tm", "wt_timer", 5)
modparam("tm", "fr_inv_timer_avp", "inv_timeout")
I'm just a little unsure as to how this is supposed to be called
(there is nothing about avp in the tm/README). When I use he above
config I don't see any mysql queries to the usr_preferences table that
would indicate where I might store a timer AVP.
Do I need to avp_db_load("$from","s:inv_timeout") or something or
should tm grab this on its own? Ultimately I'd like to have timers
that can be set up on a per user basis.
Thank you for your time.
Dan
On Tue, 15 Feb 2005 23:38:50 +0100, Jan Janak <jan(a)iptel.org> wrote:
On 15-02 11:53, Steve Blair wrote:
I understand some people have had success on this
issue with avp_ops
module in 0.9.0 but I have yet to address this issue in that release.
That's correct, in 0.9.0 you can set different timer values on per
transaction basis. TM module would pick the value for the timers from
AVPs, see fr_timer_avp and fr_inv_timer_avp parameters of tm module.
The AVPs can be loaded using avp or avpsops modules.
Note that there is a performance inpact when this feature is used, but
in real world setups it does not seem to harm.
Jan.
6:37 p.m.
Dan,
You can set the timer with something like this:
avp_write("i:45", "inv_timeout"); # set invite timer to 45 seconds
Just do this before you t_relay()
I use this to give extra time when dialing SIP->PSTN since many PSTN
phones (like cellular phones) need the extra time.
Regards,
Paul
On Wed, 16 Mar 2005 18:14:25 -0500, Daniel Poulsen <dpoulsen(a)gmail.com> wrote:
I am finally at the point where I am trying this with
0.9.0 and I have
just a couple of questions.
Jan, you state that tm will "pick up" the timers from AVP. I've
seached the list and find references to fr_inv_timer_avp that look
like this:
modparam("tm", "fr_timer", 15)
modparam("tm", "fr_inv_timer", 22)
modparam("tm", "wt_timer", 5)
modparam("tm", "fr_inv_timer_avp", "inv_timeout")
I'm just a little unsure as to how this is supposed to be called
(there is nothing about avp in the tm/README). When I use he above
config I don't see any mysql queries to the usr_preferences table that
would indicate where I might store a timer AVP.
Do I need to avp_db_load("$from","s:inv_timeout") or something or
should tm grab this on its own? Ultimately I'd like to have timers
that can be set up on a per user basis.
Thank you for your time.
Dan
On Tue, 15 Feb 2005 23:38:50 +0100, Jan Janak <jan(a)iptel.org> wrote:
On 15-02 11:53, Steve Blair wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
I understand some people have had success on this
issue with avp_ops
module in 0.9.0 but I have yet to address this issue in that release.
That's correct, in 0.9.0 you can set different timer values on per
transaction basis. TM module would pick the value for the timers from
AVPs, see fr_timer_avp and fr_inv_timer_avp parameters of tm module.
The AVPs can be loaded using avp or avpsops modules.
Note that there is a performance inpact when this feature is used, but
in real world setups it does not seem to harm.
Jan.
7091
days inactive
7120
days old
4 comments
4 participants
participants (4)
-
Daniel Poulsen -
Jan Janak -
Java Rockx -
Steve Blair