Hello List.
I have the next situation. I'm trying to build a "LCR" but using the
information from a Radius Server, so 'im using the avp_radius module to
obtain the "next_gw" data from my DB.
So far so good, I have been able to retry a failed call with the next
gateway in the list. In my tests I'm using a list of 3 gateways and I'm
seeing the next behavior : I have all the gateways off-line, so the
call is redirected to the first, second and and finally to the third
gateway, when there is no moer gateways to try I have this statement in
my config file :
if( there is gateways to try on the list... ) {
route(1);
} else {
sl_send_reply("503", "No more DB routes");
exit;
}
I send the "503 - No more DB routes" but the Kamailio also send a "408
Request Timeout".
What could this be happening? I even tried with just one gateway on the
list, with the same results. I was expecting just the "503" message,
and not the "408".
Hope that someone could help me.
I'm attaching my kamailio-snnipet.cfg file and a full debug with the
behavior.
Thanks!
Ricardo Martinez
Hi guys,
is there a way to realize TCP fail over?
With UDP, I check for 408s in the failure route and react accordingly.
With TCP, the tm modules sends out a 477 without any chance for me to
interfere.
Regards.
Hi,
When I am sending high volume calls to openser , I am getting
WARNING:tm:run_failure_handlers: no UAC or CANCEL support (1, 0).
Please help me to find out the cause of it.
I am using openser 1.2.3.
Thanks
Krunal Patel
Hello,
I want to reveal some details from the process of getting to
sip-router.org project. Next statements are from my personal point of view
-- warning: quite long message, probably boring...
When all started, back in 2001/2002, it was research and SIP Express
Router (SER). Over the time became more than that, the market demanded
new features pushed beyond a SIP proxy/router definition, the place of
this application was no longer in research, business side and telephony
industry forced to take actions.
In that context I co-founded OpenSER in 2005, leaving SER to continue
its way.
Now after several years, the situation evolved as well, SIP is clear the
today's technology for telecommunication, every Telco out there is
deploying/replacing its infrastructure with SIP. However, SIP was
designed for more than this, other companies develop innovative services
and products using this protocol. I could identify couple of directions
within our project:
- old-style-fashion switch - mapped on SIP Router/Proxy, where speed and
reliability is the main concern
- call/dialog stateful proxy (back-to-back user agent) - for a larger
set of security and service features
- pbx-like features using SIP signaling only - call pickup, shared line
appearance, etc...
- new fashion functionalities - IM&Presence, gaming, integrated and
convergent communication, application servers...
To be able to sustain and keep high level quality, it is clear that we
need more companies in, entities that are interested on different
directions of the development, so they contribute there. I am interested
in the first and last direction with higher priority, but I don't want
to leave out the other two.
Moveover, kamailio/openser is used now in many deployments, some serving
millions of users and billions of minutes per month. We need to provide
a reliable environment so more companies are confident the development
and maintenance continue. The project shall prove the maturity that is
not dependent on gringo-like actions, one company influence, forking out
of nowhere, domain hijacking, etc... this is the first goal for myself,
something I want to ensure before anything else.
sip-router.org was not one minute/meeting decision (after a beer, dinner
or one email, ...). Discussions started between different persons,
coordinated or privately, several months ago, long before the latest
fork. It was clear that SER and OpenSER made their points over the time,
one satisfying better the need for stability, performance, the other
better for innovation and flexibility. At a point in future, sooner or
later, each project would have been switched some of its resources to
the other direction.
At the time of announcement, the sip-router.org site had comprehensive
content about how this will work. It was the result of face-to-face
meetings, phone and email conversations that took place a lot in the
last months before the news. It was no decision until everyone deeply
involved in each project acknowledged that there are mutual benefits for
everybody (developers, users and businesses behind both projects) backed
up by willingness to do it in a fair manner.
I cannot talk about other projects in the x-SER eco-system, but with
Kamailio/OpenSER never was the case/proposal of merging back to SER, all
the time was about collaboration and joint effort. It will never happen
to drop our goals for innovation and flexibility. Therefore we discussed
and agreed the development mechanisms to ensure the need of each
project: a stable layer (core + tm) and innovation by modules or libraries.
Nothing was left out, every aspect, from licensing, contribution, ... to
releasing and management, was approached. The meeting in Karsruhe came
just to conclude that. All our community members were happy about
announcement, and, as a matter of fact, there were no political-like
discussions conducted between our members since sip-router.org
announcement, the focus moved on the technical side and good progress
was reached so far:
http://lists.kamailio.org/pipermail/users/2008-November/020694.html
Personally, I consulted people in open source and communication world,
that are not particularly technical or in relation with x-SER projects.
Getting to sip-router.org took more than half year since I realized a
common layer between the x-SER projects should be beneficial for everybody.
There are more things to say, but maybe not that relevant. I let them
for the time we meet at SIP Router events. Now I hope several points are
more clear:
- it is not a merge back in SER, it is a joint project (this just
because some tried to suggest it)
- the entire collaboration process was carefully discussed and planned
- it was conducted by the need of reliable, non-confusing environment --
that ensures sustainable development, innovation and rock-solid
stability, it protects the interests of developers, users and businesses
investing resources in the project.
At the end, I want to thank to Kamailio and SER management team members,
to the developers and many other people involved in both projects that
helped with this process - they dedicated lot of time and resources.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
just to let you know that yesterday evening first openser/kamailio
modules run on the common core+tm provided by sip-router project. That
was siputils (new module in Kamailio devel version).
Soon after:
- xlog module was ready too, with just an extra define in Makefile,
marking the inclusion of pseudo-variable and transformation API in
sip-router -- one can do color printing via xlog. Note that all
pseudo-variables and transformations will be moved in PV module as
discussed some time ago on Kamailio devel mailing list.
- db api of Kamailio and SER were included as library and other modules
become compilable with sip-router
For reference:
http://lists.sip-router.org/pipermail/sr-dev/2008-November/000071.htmlhttp://lists.sip-router.org/pipermail/sr-dev/2008-November/000077.htmlhttp://lists.sip-router.org/pipermail/sr-dev/2008-November/000081.htmlhttp://lists.sip-router.org/pipermail/sr-dev/2008-November/000082.html
Once MI and statistics will become libraries as well, then many other
modules shall work more or less out of the box (some statistics done in
core and 1-2 mi commands will miss in the first phase). Then in comes
the second big step, after module integration, config language update --
after that point we are kind of 70% ready.
All these happened in just few days since source code repository (GIT)
was up ... it looks like we will get most of the features from
Kamailio/OpenSER and SER together sooner than I expected ... let's see ...
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
last month was very busy for myself, with lot of work and traveling for
the sip-router.org, so apart of announcing few updates, I focused on
getting things done rather than going in pointless discussions. I will
send couple of other emails related to this subject.
However, there was one person writing untrue statements and offending
the developers of Kamailio/OpenSER on mailing lists, web and IRC
channels. If he would have searched a bit on the net, have talked with
our developers, he would realize that people in our team are very rich
in skills and experience, then probably he would refrain from statements
like "no skills", "no knowledge".
Until someone else than him, recognize him as the greatest, gets the
Nobel prize, publishes world recognized books or standards, so I can
take his opinion in consideration, the development of Kamailio/Project
is ensured by people such as:
- Juha Heinanen, doctor in computer science, former professor at
Tampere University, author of many RFCs, and the list can continue ...
from the web:
http://occamnet.com/company/directors_and_advisors/jheinanen.cfmhttp://www.arkko.com/tools/rfcstats/juhaheinanen.html
- Klaus Darilion, doctor in computer science at Technical University
Vienna, involved in ENUM and security of VoIP/SIP, author/contributor to
several open source applications and papers related to these domains
http://www.ipcom.at/index.php?id=565
- Henning Westerholt, computer science engineer, in charge with the
biggest VoIP deployment based on Kamailio/OpenSER I ever heard of: about
2 000 000 users, 5 000 000 phone numbers, 1 000 000 000 routed minutes
per month. It is at least twice bigger than other deployments of
openser/kamailio I am aware of.
http://www.1und1.de
I am stopping here, but all the other members of Kamailio/OpenSER devel
team have broad knowledge in computer programming and VoIP technologies,
authored or contributed to other open source applications -- just google
the names. As co-founder of this project I felt is my duty to show the true.
Therefore those statements are proofless and it is sad to see somebody
can come up with such things. The development of Kamailio/OpenSER
boosted since release 1.4, in summary:
http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.xhttp://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x
and we are not ready yet with the new features for 1.5. Meanwhile,
effort is directed to sip-router.org project as well -- I will post a
status update soon.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Hi Daniel,Nice photos, but would you mind to put names of the participant in
the photos??? i think that could be much better.
Rgds,
Lu.
--
Luzango Mfupe
TUUNE MOBILE
Tel:0128440528/0123825710
Tshwane-RSA
"...Ships are safe in harbor, but they were never meant to stay
there......."
We are trying to configure the ACC module to log the Reason: header found in
SIP BYE and SIP 4xx messages sent by US carriers when making calls to the
PSTN.
We have added a cause field (the Reason header contains the Q.850 cause code
associated with telephony events, typically disconnect) to the acc and
missed_calls tables (see tables description further below) and changed
opensips.cfg to read that header and store it:
modparam("acc", "db_flag", 2)
modparam("acc", "db_missed_flag", 3)
modparam("acc", "db_url", "mysql://root:password@localhost/opensips")
modparam("acc", "db_extra",
"from_uri=$fu;to_uri=$tu;request_uri=$ru;cause=$(hdr(Reason))")
This works quite nicely for calls logged in the acc table, such as:
mysql> select * from acc where date(time) = curdate() and (cause like
'%850%') limit 1;
+---------+--------+---------------+-----------------------+-----------------------------------------------------+----------+------------+---------------------+---------------------------------+---------------------------------+-----------------------------------+----------------+
| id | method | from_tag | to_tag | callid
| sip_code | sip_reason | time | from_uri
| to_uri | request_uri |
cause |
+---------+--------+---------------+-----------------------+-----------------------------------------------------+----------+------------+---------------------+---------------------------------+---------------------------------+-----------------------------------+----------------+
| 1903785 | BYE | 627B7414-1509 | telstage-3e5-492294f9 |
492294f9-0127-00105838-0657a1e7-22e4c653(a)88.88.88.88 | 200 | Ok
| 2008-11-18 05:12:55 | sip:+5599999999@99.99.99.99 |
sip:+15555555555@88.88.88.88:5060 | sip:88.88.88.88:5060;transport=udp |
Q.850;cause=16 |
+---------+--------+---------------+-----------------------+-----------------------------------------------------+----------+------------+---------------------+---------------------------------+---------------------------------+-----------------------------------+----------------+
1 row in set (1.58 sec)
The cause field contains "Q.850;cause=16" taken from the Reason: header.
However, the same Reason: header is NOT logged for calls found in the
missed_calls table:
mysql> select * from missed_calls where date(time) = curdate() and sip_code
= 480 limit 1;
+---------+--------+------------------------+--------------+-----------------------------------------------------+----------+---------------------------+---------------------+---------------------------------+---------------------------------+---------------------------------+-------+
| id | method | from_tag | to_tag | callid
| sip_code | sip_reason | time | from_uri
| to_uri | request_uri | cause
|
+---------+--------+------------------------+--------------+-----------------------------------------------------+----------+---------------------------+---------------------+---------------------------------+---------------------------------+---------------------------------+-------+
| 1231364 | INVITE | telstage-5d06-492293b5 | 627682C8-40F |
492293b5-0154-0013be65-6d9882a2-bafcf3d3(a)88.88.88.88 | 480 |
Temporarily Not Available | 2008-11-18 05:06:51 |
sip:+15555555555@88.88.88.88:5060 | sip:+5599999999@63.63.63.63 |
sip:69085599999999@200.0.0.0 | |
+---------+--------+------------------------+--------------+-----------------------------------------------------+----------+---------------------------+---------------------+---------------------------------+---------------------------------+---------------------------------+-------+
1 row in set (1.09 sec)
Note that the cause field is empty, while the OpenSIPS logs clearly show a
Reason: header present in the SIP 480 message:
Nov 18 05:06:51 sip100 /usr/local/sbin/opensips[20355]: TRACE:ONREPLY_ROUTE:
src(200.0.0.0:5060) dst(63.63.63.63:5060) msg(SIP/2.0 480 Temporarily Not
Available^M Via: SIP/2.0/UDP
63.63.63.63;branch=z9hG4bK96cf.a009bc13.0,SIP/2.0/UDP
88.88.88.88:5060;branch=z9hG4bK492293b5-0154-0013be66-6d9882a2-bafcf3d3^M
From: <sip:+15555555555@88.88.88.88:5060>;tag=telstage-5d06-492293b5^M To:
sip:+5599999999@63.63.63.63;tag=627682C8-40F^M Date: Tue, 18 Nov 2008
10:06:45 GMT^M Call-ID:
492293b5-0154-0013be65-6d9882a2-bafcf3d3(a)88.88.88.88^M Server:
Cisco-SIPGateway/IOS-12.x^M CSeq: 13960 INVITE^M Allow-Events:
telephone-event^M Reason: Q.850;cause=18^M Content-Length: 0^M ^M )
Is this a bug from the ACC module or a limitation, i.e. SIP 4xx messages are
not handled in the same way as the BYE messages in the acc table?
Any advice would be most appreciated!!
Serge
PS: here are the schemas we're using for the acc and missed_calls tables:
mysql> describe acc;
+-------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| method | varchar(16) | NO | | | |
| from_tag | varchar(64) | NO | | | |
| to_tag | varchar(64) | NO | | | |
| callid | varchar(64) | NO | MUL | | |
| sip_code | varchar(3) | NO | | | |
| sip_reason | varchar(32) | NO | | | |
| time | datetime | NO | | | |
| from_uri | varchar(64) | NO | | | |
| to_uri | varchar(64) | NO | | | |
| request_uri | varchar(64) | NO | | | |
| cause | varchar(60) | YES | | NULL | |
+-------------+------------------+------+-----+---------+----------------+
12 rows in set (0.00 sec)
mysql> describe missed_calls;
+-------------+------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| method | varchar(16) | NO | | | |
| from_tag | varchar(64) | NO | | | |
| to_tag | varchar(64) | NO | | | |
| callid | varchar(64) | NO | MUL | | |
| sip_code | varchar(3) | NO | | | |
| sip_reason | varchar(32) | NO | | | |
| time | datetime | NO | | | |
| from_uri | varchar(64) | NO | | | |
| to_uri | varchar(64) | NO | | | |
| request_uri | varchar(64) | NO | | | |
| cause | varchar(60) | YES | | NULL | |
+-------------+------------------+------+-----+---------+----------------+
12 rows in set (0.00 sec)
--
View this message in context: http://www.nabble.com/ACC-module-issue-logging-Reason%3A-SIP-header-in-miss…
Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.
Hi all,
I'm using openser 1.3.3. And I found an issue between asterisk and
openser.
When an asterisk register himself to openser this is my opeserctl ul
show:
Contact:: sip:s@172.25.18.168 Q=
Expires:: 116
Callid:: 76e873601b776e8a430237091a76a483(a)172.25.18.168
Cseq:: 103
User-agent:: Asterisk PBX 1.4 Test
State:: CS_DIRTY
Flags:: 0
Cflag:: 0
Socket:: udp:172.25.18.163:5060
Methods:: 4294967295
In to the postgres database into location table I have
2;"50001";"ttnnet.it";"sip:s@172.25.18.168";"";"";"2008-11-13
10:56:24";-1;"76e873601b776e8a430237091a76a483(a)172.25.18.168";108;"2008-11-13 10:54:24";0;0;"Asterisk PBX 1.4 Test";"udp:172.25.18.163:5060";
As you can see the methods field into the database is null!
This causes an issue when you restart openser, the asterisk pbx is
unreachable until the next registration because the lookup function
doesn't match the methods field.
The number 4294967295 is the max int (without sign), maybe there is a
issue in the function that calculate this value and post the query.
Any clue?
Kind regards
Matteo
please cc always to mailing lists...
On 11/18/08 18:30, Sebastian sastre wrote:
> Daniel,
>
> Thanks a lot for the info. I was playing with the scripts yesterday to
> find a workaround.
>
> When I call my perl script with perl_exec() if I rewrite the headers
> with
>
> $m->rewrite_ruri("sip:A@B");
>
> They never get overwritten.
>
rewrite_uri should set a new request URI, not headers. What do you
expect to be overwritten?
Daniel
> Is there a way to access the $ru variable from the script?
>
> I also tried using the Avpops module but no luck.
>
> Thanks !!!
>
> Sebastian Sastre
> Senior Network Engineer
>
>
> NextCommunications, Inc.
> 100 North Biscayne Blvd. Suite 900
> Miami, FL. 33132. USA
> Phone: +1-305-356-4558
> Main: +1-305-356-454528
> Fax: +1-305-374-4081
> e-mail: sebas(a)nextcommunications.com
>
> -----Original Message-----
> From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
> Sent: Tuesday, November 18, 2008 6:14 AM
> To: Sebastian sastre
> Cc: users(a)lists.kamailio.org
> Subject: Re: [Kamailio-Users] [OpenSER-Users] Perl module and
> moduleFunction()
>
> Hello,
> On 11/14/08 01:54, Sebastian sastre wrote:
>
>> Hello,
>>
>>
>>
>> I am interested in knowing which flags I can set to have the
>> sl_send_reply work from a perl script.
>>
>>
> be careful, it is prety dangerous -- the undocumented parameter is
> "unsafemodfnc", set it to 1.
>
> Cheers,
> Daniel
>
>
--
Daniel-Constantin Mierla
http://www.asipto.com