Hi!
I tried
#!subst "/IPADDRESS_VIRTUAL/83.136.32.161/"
listen=udp:IPADDRESS_VIRTUAL:5060
and
#!define IPADDRESS_VIRTUAL 83.136.32.161
listen=udp:IPADDRESS_VIRTUAL:5060
Both do not work - am I doing something wrong or is this a known
limitation with "listen" statements?
Thanks
Klaus
Hi!
Every time I use the dispatcher(k) module I am confused again. Sometimes
it seems that "probing" is a dedicated state, sometimes it seems that
"probing" is done also in "active" state, but never in "inactive" state.
IMO "probing" should only be a flag which indicates if OPTIONS should
sent or not. If probing is successful, then the state should be
"active". If probing is unsuccessful, then the state should be "inactive".
Current behavior is very strange (ds_probing_mode(0)):
--> startup state: A --> no probing
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> no probing
kamctl fifo ds_set_state a 1 sip:....
--> state: A --> no probing
calling 3 times ds_mark_dst("p")
--> state: P --> probing (and dst is still loaded as last value into the
dst_avp, why?)
kamctl fifo ds_set_state i 1 sip:....
--> state: I --> still probing
kamctl fifo ds_set_state a 1 sip:....
--> state: P (???) --> probing
Thus, "ds_set_state a ..." does not set active, but probing if it was
probing before. Strange.
And as "inactive" does not stop probing when dst was in probing mode,
the destination becomes automatically "active" if the probing succeeds.
And why is a destination in probing mode loaded into the dst_avp? Very
weird.
Is there a reason for this behavior?
Thanks
Klaus
Hello list,
I have a question to the dispatcher module in Kamailio version 3.0.4.
In my integration I use this module for distributing calls to a set of
gateways (with the round robin algorithm). Sometimes a gateway does not
react or send back a negative response. In that case I use the function
'ds_mark_dst("p")' in the failure_route and mark the current destination
with the flag 'probing'. I have set the threshhold value for probing mode
to '10'. This means that a gateway is effectively set to probing mode only
when it was marked with the flag 'probing' for 10 times. However,
sometimes a gateway is sending back a negative response for e.g. 5 times
and is afterwards working fine - without any problems. A few hours later
(e.g.) it is sending a negative reply again for one time. This means: the
counter for the probing_flags is increasing every time when the function
ds_mark_dst("p") is executed (in case that the process was not restarted
in the meantime!). So the problem is, that the counter is reaching the
threshhold value at any time and at that moment the gateway is set to
probing mode. Even if the gateway has sent a negative reply for only one
time (at that moment) - but according the history the proging_flag was set
several times.
What I miss in this module is a function to _reset_ that flag counter from
a REPLY_ROUTE. Note: I have to reset the counter, because the gateway does
not yet SIP OPTIONS requests and therefore it is set to 'probing' all time
until it is manually set back to active via MI command or after a process
restart. According the README file (and practical experience) the function
ds_mark_dst() is executable only within the failure_route. However, when I
want to set the flag ("a") for the current destination I will do it within
a reply_route, but not in the failure_route (because I have received a
positive response and not a negative one). From my point of view it does
not make sense setting the 'active' flag for a destination from within a
FAILURE route.
Does anybody have an idea, how the 'flag-counter' could be reset (from
within the script)? I do not want to use a MI command.....
configuration excerpt:
[...]
modparam("dispatcher", "db_url",
"mysql://openser:openserrw@localhost/openser")
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")
modparam("dispatcher", "ds_ping_from", "sip:proxy@192.168.37.87")
modparam("dispatcher", "ds_probing_mode", 0)
modparam("dispatcher", "ds_probing_threshhold", 10)
modparam("dispatcher", "ds_ping_interval", 30)
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "force_dst", 1)
[...]
if (!ds_select_dst("1", "4")) {
sl_send_reply("404", "No destination (disp)");
exit;
}
t_on_failure("failureroute");
t_on_reply("replyroute");
[...]
failure_route[failureroute] {
[...]
if (t_check_status("[45][08]0") || (t_branch_timeout() &&
!t_branch_replied())) {
ds_mark_dst("p");
if (!ds_next_dst()) {
t_reply("404", "No destination (disp)");
exit;
}
t_on_failure("failureroute");
t_on_reply("replyroute");
}
[...]
}
onreply_route [replyroute] {
if (t_check_status("180|200") {
# nice to have......
# ds_mark_dst("a");
}
}
Thanks in advance!
regards,
Klaus
Greetings-
I'm attempting an installation of Siremis on a CentOS 5.5 64-bit system running Kamailio 3.1.0. Following the instructions on the wiki [1], I find that I cannot pass step 3 for the database configuration.
I've triple checked all of my details are correct and verified the permissions are set appropriately on the Siremis source dir. Also, I've successfully run 'make apache-config' and 'make prepare'. After clicking 'next', I simply get the 'Loading... please wait awhile' graphic. On three different fresh installs, I've waited for 3 hours each.
By now, I have to assume it shouldn't be taking this long and there is an error somewhere. The Apache logs don't indicate anything of interest other than a missing favicon.
Do you have any ideas?
Thank you!
--Tim
[1] http://kb.asipto.com/siremis:install20:main
Hi,
I'm wondering if there is a easy way to limit the call duration in Kamailio
? I would like to automaticaly end the call when the max. duration (for
example 12 hours) is reached.
In the feature overview of Kamailio 1.5 I found: "option to send BYE when
dialog expires" but i'm can't figure out how to get this working (if it's
still implemented at all in the current version).
Thanks in advance,
Kind regards
Hans
we noticed that if sr 3.1 config does not contain
syn_branch=0
then acks to 200 oks that are t_relayed by sr, contain branch=0
param in topmost via.
in kamailio 1.5, via branch param has proper value even when tm param
syn_branch is not set.
a couple of questions:
1) according to core cookbook, syn_branch core param only affects
stateless forwarding. in my config, all acks are t_relayed, i.e.,
syn_branch param should not have any effect, but is does. how is that
possible? is there a bug in core cookbook?
2) should t_relaying of acks to 200 oks use proper (i.e.. non 0) via
branch param even when syn_branch is not set to any value in config?
if not why? if yes, will branch=0 be used only when ack to 200 ok does
not match any invite transaction?
-- juha
Hello all,
I've read as many of the asterisk balancing threads as I can find. Either
my situation is unusual or I simply haven't understood anything I've read.
In short, I'm building an web/phone mashup which uses Asterisk's AGI to get
its work done. My only users are on the PSTN connected to Asterisk through
a SIP trunk provider. So presently, in and out through the same trunk, apps
live on the single Asterisk box.
My goal is scaling and failover. I don't have any need for cross talk or
transfers between the asterisk instances, and the algo's in dispatcher seem
fine. It seems to me that I should be setting the sip-router up a
replacement for the existing peer in Asterisk. What leaves me scratching my
head is how I then register the sip-router with the upstream provider.
Alternatively, if I use the sip-router as an outboundproxy from asterisk
(which seems like it's going to take some hacking to make this work in 1.4),
doesn't this now mean I have multiple UAC's trying to register for the same
name?
Can someone set me on the right track?
Thanks,
Andy Lippitt
I am a newbie to the world of VIOP. I am attempting to set up an ATA with SIP.
I created a SIP at account iptel.com and received an email
confirmation stating "We are reserving the following SIP address for
you: sip:larry.baumbach@iptel.org".
I tried to testing this address in Xlite but got messages saying:
"Account failed to enable. Account Iptel could not be enabled.
Verify your user ID, password and authorization name.
When I set up the SIP account in Xlite I used:
UserID: larry.baumbach(a)iptel.org ( I also tried
"larry.baumbach" & "sip:larry.baumbach@iptel.org")
Domain: sip.iptel.org
Password: my password
Authorization name: (I left blank as I did not receive any)
I can log into SERweb with the same UserID and Password and access my account.
What am I doing wrong? Or is there some kind of wait time before my
SIP address is activated?
I have spent too much time trying to get this to work on my own.
Thanks very much for any help you can provide.
--
Larry Baumbach
920.358.8695
larry.baumbach(a)gmail.com
Hi,
whats about: http://sip-router.org/tracker/index.php?do=details&task_id=108 I think that some users are trying to register to an asterisk system. Or does somebody have a solution for that?
A new release would be nice!!!
Thanks in advance.
Best regards,
Bernhard
----- Original Message -----
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
To: kamailio [mailto:sr-users@lists.sip-router.org], sr-dev [mailto:sr-dev@lists.sip-router.org]
Sent: Fri, 28 Jan 2011 20:15:50 +0100
Subject: [sr-dev] planning release of v3.1.2
> Hello,
>
> I think it is time to release v3.1.2, first date that comes in my mind
> is next Thursday if everyone feels it is enough time to take care of
> backporting any fix he/she did and it is not yet there. That will
> provide us a fresh release for the FOSDEM event. If not, then maybe the
> other week, Tuesday, so the participants at the Kamailio Devel training
> in Barcelona can practice on it.
>
> Soon after we should plan also a release for previous stable, branch 3.0.
>
> Anyone having other options?
>
> Thanks,
> Daniel
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
