Hi all,
Is the setflag command used only with the acocunting module? I noticed that it is present in the mediaproxy config file from onsip.org. I was wondering if it is necessary?
Thanks,
George
Hi again list,
I'm trying to get acc module to work so that I can write a billing
script for SER (which I'll probably stick on CPAN just like what I've
done for Asterisk::LCR).
Thanks to Olivier Taylors' help now the module works (well, at least SER
starts). But I see no trace of my BYE messages. Which is strange since I
do record route (well, I think I do).
I have pasted my ser.cfg on http://pastebin.ca/38650
Can you see what's going wrong? I would really like to avoid using
Asterisk *just* to be able to bill stuff.
--
Jean-Michel Hiver - http://ykoz.net/
Découvrez la Réunion des Technologies IP & Telecom
TEL: +262 (0)262 55 03 98 - RCS 434 273 330 SAINT PIERRE
Hello,
I am pretty new to all of this, so I hope somebody give me some help.
I am trying to get SER working with a Cisco AS5350 and some Cisco SIP
phones,
can somebody help me with some configs of the AS5350 and how ser.cfg should
look like.
The SIP phones can already call each other but it is the forward to the
as5350 that is giving me problems.
I am thinking I am experimenting with to much things that could be wrong, so
it would be nice to have some working configs.
Regards,
Jeroen
Hi all...
Sorry this is a bit long, but this problem is driving me nuts...
I have a problem where I need to try a sequence of numbers on the PSTN, where
the one is tried if the previous one fails or times out. My problem is
handling the timeout (408) case:
1. First INVITE sent to PSTN gw
2. final response timer fires, fake 408 generated
3. failure_route in scripts called, new branch created, next INVITE sent to
PSTN gw
4. CANCEL is sent (I realize this is not sync'd to step 3 but it typically
happens this way that that causes my problem)
5. PSTN GW sends 482 Loop Detected back to me for the *second* branch created
in 3.
Of course the second branch fails and that number is never tried at that point.
I understand from looking at the code in timer.c that this sequence is by
design.
What I need is for the CANCEL to come out *before* the next INVITE, and I need
to be able to reasonably ASSume that the CANCEL was received by the PSTN gw and
my invite will not trigger loop detection. I've fielded two different ways of
doing this, both of which make me feel uneasy. Both of these involved mucking
with final_response_handler in tm/timer.c. After the line:
DBG("DEBUG: final_response_handler:stop retr. and send CANCEL (%p)\n", t);
I changed the rest of the function first to read as follows (try not to laugh
too hard):
cancel_branch(t, r_buf->branch);
sleep(1);
fake_reply(t, r_buf->branch, 408 );
DBG("DEBUG: final_response_handler : done\n");
I'm a little uneasy about scheduling that cancel while the reply is locked, but
it *seems* safe. I also didn't like the fact that I was hard-coding the time,
I'd rather have it linked a bit more to the gateway processing the CANCEL,
so...
Then I tried this:
if(should_cancel_branch(t, r_buf->branch))
{
int timer = 2;
DBG("DEBUG: final_response_handler: cancel hack (%p)\n", t);
UNLOCK_REPLIES(t);
cancel_branch(t, r_buf->branch);
fr_tl->timer_list= NULL; /* set to NULL so that set_timer will work */
set_timer( fr_tl, FR_INV_TIMER_LIST, &timer );
}
else
{
DBG("DEBUG: final_response_handler: timeout (%p)\n", t);
fake_reply(t, r_buf->branch, 408 );
}
DBG("DEBUG: final_response_handler : done\n");
This gives me the link between the final from the cancel being received, and
the send of the second invite, but it has the unwanted effect of causing the
status when the failure_route script is called to always be 487, so I'd need a
way to communicate to scripts that the 487 is really the result of a local
cancel triggered by the fr_timer firing. I could theoretically get that by
re-running branch picking and checking the uac for that branch for a local
cancel, but that doesn't seem clean.
Presumably if I put a hack in place like this, it would default to off, and I'd
use a flag or something on the message before t_relay()ing the original request
to signal to tm that I want this treatment for this transaction, but I digress.
What I really need is a way to make everything look normal to the scripts (i.e.
t_check_status will still match to a 408), but gets me the CANCEL sequence I
need.
Any ideas? Am I a bad person for trying the code above? ;)
Thanks,
Phil
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi All,
What does this error mean?
Jan 26 17:42:13 sip01 /usr/local/sbin/ser[23745]: Maxfwd module-
initializing
Jan 26 17:42:13 sip01 /usr/local/sbin/ser[23745]: ERROR: auth_radius: can't
get code for the Sip-Session attribute value
Jan 26 17:42:13 sip01 /usr/local/sbin/ser[23745]: init_mod(): Error while
initializing module auth_radius
I'm using ser 0.9.5 and radiusclient-ng 0.5.2.
Thank You
Regards,
Nhadie
Hi,
I apt-get installed ser_acc_db_module and tried to configure it. After
restarting SER, SER simply doesn't reply to any REGISTER command. It
seems to just ignore them so my phones cannot register. And I have no
NAT issues either since I don't use NAT with SIP.
Here's what I did at the configuration level:
Firstly, I have added the following config to load and configure the
acc_db module.
<bunch of loadmodule statements>
# ACC
#loadmodule "/usr/lib/ser/modules/acc_db.so"
#modparam("acc", "db_url", "sql://ser:heslo@localhost/ser")
#modparam("acc", "db_flag", 1)
#modparam("acc", "db_missed_flag", 1)
#modparam("acc", "failed_transactions", 1)
<bunch of modparam statements>
Then, just after the "Record route" section and the "Loose route
section", I have added this:
#
-----------------------------------------------------------------------
# Sets the acc accounting flag 4 billing info.
#
-----------------------------------------------------------------------
if( (method=="INVITE") || (method=="ACK") || (method=="BYE")) {
setflag(1);
};
Below I have my PSTN hookup, such as:
# -----------------------------------------------------------------
# Pass on stuff going to PSTN to Asterisk
# -----------------------------------------------------------------
if (src_ip==<trusted_customer_ip>) {
if (lookup("location")) {
t_relay();
break();
};
rewritehostport ("<asterisk_gw_ip>:5060");
if (!t_relay()) {
# sl_send_reply ("403", "prout");
sl_reply_error();
};
break;
};
Any ideas of what can be going on? As soon as I comment out acc-db
related config and restart SER everything works smoothly again.
Cheers,
Jean-Michel.
Hi.
Till now I was happy using SER handling communications between UAs using
nathelper and RPT proxy.
Now I changed the ser.cfg script to the one with PSTN support and none of
the UAs get registered.
I am getting a 403 Forbidden.
Analyzing the script I understood that this 403 was coming from the Call
Type Processing Section so I changed
if (!is_uri_host_local()) {
if (is_from_local() || allow_trusted()) { and so on
to
if (uri!=myself)
and now the UAs are registering again.
But of course I can't make calls.
So I would like to know how this< is_uri_host_local and is_from _local>
work and what should I do to make them allow my UAs to register.
Thanks in advance
Juan Ferrari
Hi all,
Is SER a B2BUA for IM, voice etc?
i.e. If user A sends an IM message(via SIP MESSAGE) to SER, and SER
sends the message to user B.
Seems like it is not, because the Call-IDs are the same on both call
legs....
Is there any special configuration which can turn it into a B2BUA?
Regards,
Dennis
