Hi!
I recently had a problem with Kamailio 3.1.4 (provided Debian packages):
I had some DB problems (missing tables). Thus, the timer module failed
to insert the statistics (for siremis):
ERROR: db_mysql [km_dbase.c:120]: driver error on query: Table
'kamailio.statistics_tmx' doesn't exist
ERROR: <core> [db_query.c:130]: error while submitting query
ERROR: sqlops [sql_api.c:217]: cannot do the query
This happened for some time (weeks?), other DB queries were unaffected.
Then, suddenly Kamailio ran out of memory:
ERROR: <core> [sip_msg_clone.c:506]: ERROR: sip_msg_cloner: cannot
allocate memory
ERROR: tm [t_lookup.c:1338]: ERROR: new_t: out of mem:
ERROR: tm [t_lookup.c:1478]: ERROR: t_newtran: new_t failed
ERROR: sl [sl_funcs.c:282]: ERROR: sl_reply_error used: I'm terribly
sorry, server error occurred (1/SL)
It do not think it is a load problem as the server is more or less idle.
May it be a memory leak due to wrong error handling?
Where there any fixes recently?
Thanks
Klaus
Hi,
I have installed Siremis 2.0.0 and Kamaillio 3.2.0 on a OpenSuse 11.4 system.
After the Siremis Web Installation Wizard finished the setup the login failed with a http error 404.
The Apache2.0 error_log shows:
[Mon Oct 31 11:09:49 2011] [error] [client ::1] File does not exist: /var/www/siremis-2.0.0/siremis/system, referer: http://localhost/siremis/index.php/user/login
The Apache2.0 access_log shows:
::1 - - [31/Oct/2011:11:09:36 +0100] "GET /siremis/bin/antispam_image.php?form=user.form.LoginForm&name=antispam&length=6&level=2?rand=1768032447 HTTP/1.1" 200 240 "http://localhost/siremis/index.php/user/login" "Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
::1 - - [31/Oct/2011:11:09:48 +0100] "POST /siremis/bin/controller.php?F=RPCInvoke&P0=[user.form.LoginForm]&P1=[Login]&__this=btn_login:onclick&jsrs=1 HTTP/1.1" 200 214 "http://localhost/siremis/index.php/user/login" "Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
::1 - - [31/Oct/2011:11:09:49 +0100] "GET /siremis/system/general_default HTTP/1.1" 404 1331 "http://localhost/siremis/index.php/user/login" "Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
Is there anybody how can help me out of this?
Regards,
Uwe Andersen
On 10/31/11 2:09 PM, Vladimir Broz wrote:
> ah, that was the problem :(
ok. Don't forget to keep the mailing list always cc-ed, so people
reading the archive for similar issues will find the conclusion, whether
the hints were solving or not the problem.
Cheers,
Daniel
>
> Thanks Daniel!
> -Vlada
>
> On 10/31/2011 01:37 PM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> be sure you load uac module from modules_k, not from modules_s.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 10/31/11 12:36 PM, Vladimir Broz wrote:
>>> ignore the "sip:b@@test.com" -> same result with the correct (only one
>>> "@") value
>>>
>>> Thanks,
>>> -Vlada
>>>
>>> On 10/31/2011 12:21 PM, Vladimir Broz wrote:
>>>> Hi,
>>>>
>>>> I compiled 3.2 (master) with FLAVOUR=ser and I'm trying to use "uac"
>>>> module.
>>>>
>>>> my config looks like:
>>>> ...
>>>> $uac_req(method)="NOTIFY";
>>>> $uac_req(ruri)="sip:server.test.com";
>>>> $uac_req(furi)="sip:a@test.com";
>>>> $uac_req(turi)="sip:b@@test.com";
>>>> ...
>>>>
>>>> and I'm getting this config file error
>>>>
>>>> 0(26125) ERROR: <core> [pvapi.c:706]: error searching pvar "uac_req"
>>>> 0(26125) ERROR: <core> [pvapi.c:910]: wrong char [m/109] in
>>>> [$uac_req(method)] at [9 (5)]
>>>> 0(26125) : <core> [cfg.y:3501]: parse error in config file
>>>> /root/vbroz/ser-srrs-bpi.cfg, line 388, column 2-17: unknown script
>>>> pseudo variable $uac_req(method)
>>>> ERROR: bad config file (1 errors)
>>>>
>>>> What's wrong?
>>>>
>>>> Any help is appreciated...
>>>>
>>>> Thanks in advance,
>>>> -Vlada
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>> list
>>>> sr-users(a)lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users(a)lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
---------- Forwarded message ----------
From: Uri Shacked <uri.shacked(a)gmail.com>
Date: Sun, Oct 30, 2011 at 12:16 PM
Subject: how to retrieve the contact username from 3xx reply?
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users
Mailing List" <sr-users(a)lists.sip-router.org>
I need to store the user i get from the 301 reply to an AVP and use it
afterwards in another route.
How can i retrieve the contact from the 3xx reply?
uac_redirect does not have this option and t_load_contacts does not work
for me as well....
Anyone has an idea?
Hello,
How can i change T1 timeout for transaction created by the UAC module
(uac_req_send).
Do i have to call t_set_retr before uac_req_send and then t_reset_retr()
before t_relay ?
I use uac_req_send to send accounting to the remote server and i want to
increase retransmit timeout for such signalling messages.
FYI
-------- Original Message --------
Subject: [RAI] SIPit 29 Summary
Date: Fri, 28 Oct 2011 09:40:51 +0200
From: Robert Sparks <rjsparks(a)nostrum.com>
To: rai(a)ietf.org
(also available at https://www.sipit.net/SIPit29_summary)
SIPit 29 was hosted by Etsi Plugtests in Monte Carlo, Monaco
the week of October 24-27, 2011.
There were 34 attendees from 17 companies visiting from 12 countries.
We had 25 distinct implementations.
The roles represented (some implementations act in more than one role)
20 endpoints
5 proxy/registrars
The b2buas attending this event were not attempting to appear to be proxies.
Implementations using each transport for SIP messages:
UDP 92%
TCP 96%
TLS 88% (24% server-auth-only)
SCTP 8%
DTLS 0%
44% of the implementations present supported IPv6.
There were three RFC4474 Identity implementations present.
For DNS we had support for:
Full RFC3263 : 76%
SRV only : 16%
A records only : 08%
no DNS support : 0%
Support for various items in the endpoints:
75% replaces
50% ice
40% 5389stun
35% turn
25% sip/stun multiplexing
30% gruu
25% history-info (there were no implementations of 4244bis)
20% outbound
20% path
20% diversion
15% 3489stun
10% join
5% service-route
0% sigcomp
Support for various items in the proxy/registrars:
100% path
80% sip/stun multiplexing
60% gruu
40% outbound
40% diversion
20% service-route
0% history-info
The endpoints and b2buas implemented these methods:
100% INVITE, CANCEL, ACK, BYE
95% REFER
95% NOTIFY
80% REGISTER
80% INFO
75% OPTIONS
75% UPDATE
75% PRACK
60% SUBSCRIBE
35% MESSAGE
30% PUBLISH
100% of the implementations sent RTP from the port advertised
for reception (symmetric-rtp).
30% of the implementations required the other party to use symmetric-rtp.
90% of the UAs present both sent RTCP and paid attention to RTCP they
received.
80% of the endpoints present supported SRTP using sdes.
There were no dtls-srtp implementations at this SIPit.
35% of the endpoints supported multipart/MIME.
There were no implementations present with S/MIME support.
36% of the implementations present followed RFC6026 (corrections
to the INVITE transaction)
36% followed RFC4320 (corrections to the non-INVITE transaction)
Not counting implementations that support events only for REFER:
There were 3 SIP Event Server implementations
There were 5 SIP Event Client implementations
These event packages were supported:
Server Client
1 2 presence
1 1 presence.winfo
1 4 message-summary
1 1 dialog
1 1 reg
1 1 conference
1 1 xcap-diff
0 2 kpml
These packages were supported with the eventlist extension:
Server Client
0 1 presence
Two of the proxies present still rely only on max-forwards and
one that implemented 3261 loop detection. There were two implementations
of fork-loop-fix, but no implementations of max-breadth.
Multiparty tests (Notes provided by several test participants, including
Eoin McLeod, Trond Andersen, Olle Johansson, and Adrian Georgescu)
** IPv6 Focused Tests
The first multiparty session of the event focused specifically on IPv6.
We used
a basic forking scenario with endpoints registered with several proxies
at the
bottom of the tree. We had a mix of single and dual-stack endpoints, many
supporting video.
None of the participant's code would put both v4 and v6 candidates into ICE.
Rather, it made assumptions about which candidates to use based on what was
happening with the SIP signaling. We ran tests using SRV configurations
stating
that v6 should be tried first and v4 tried if the v6 failed (and a second
configuration that tested v4 first) to ensure that implementations would
fail
forward and try both address families, with mixed results. We confirmed that
one UA configured to use IPv6 only was able to request and use an IPv4 turn
allocation and succeeded in making a call between an IPv4 UA and IPv6 ua.
Most UAs that supported dual-stack had a configuration to tell the
application
to ignore any returned AAAAs due to issues encountered in deployments where
endpoints autoconfigured IPV6 that didn't actually work. We successfully
tested
calls going though a mix of v4 and v6 hops (accruing Via and
Route/Record-Route
headers with addresses in both families.
There was an instance of UA registering using sip-outbound (RFC5626)
that used
IPv4 and IPv6 flows simultaneously.
We set up automated tests of using SRV records to indicate preference
for IPv4
or IPv6. Two ipv4 only clients proved that they connect to a domain
indicating
preference for IPv6.
** Forking
There are still UAs that do not sensibly handle multiple 200 OKs to
a forked INVITE.
When testing handling multiple 200 OKs on a simple two branch fork, we
encountered an interesting failure. As the proxy handled the 200 OK from
branch
1, it sent a CANCEL to the other branch. The UA on branch 2 had already
responded with a 200 OK, so it responded to the CANCEL with a 200, but
rather
than ignoring it, it decided to send a BYE on the dialog. This surprised the
calling UA which had chosen the 200 OK from branch 2 to keep, having already
sent a BYE to the dialog from branch 1. The better thing for the UA to have
done is ignore the CANCEL after replying to it.
** TLS
Most of the implementations at the event supported TLS, and all the
multiparty
tests exercised it. One session focused on proper certificate
verification. We
tested a certificate at a server with several SAN URI fields, none of which
matched the URI used for the server, but a CN that did. Only one UA
failed to
connect because of this, the rest of the UAs connected happily (or not
at all,
but because of other issues). Most of the implementations were "before 5922"
code, which meant that there was a lot of checking of the Subject/CN.
** Identity
There were several SIP Identity implementations present. We tested
creating and
verifying the Identity assertions at proxies. It wasn't immediately
obvious to some
implementers that the resource pointed to by the Identity-Info URI had
to be DER
encoded (a result of the requirement to use application/pkix-cert).
Unfortunately,
the tar encoded at the end of 4474 has .cer files in it that are PEM
encoded.
** STUN/TURN/ICE and Outbound
We spent a significant fraction of the multiparty test time (three sessions)
focusing on STUN/TURN/ICE and Outbound.
There are still clients using RFC 3489 STUN.
The participants noted operator pushback against deploying ICE because when
things go wrong, it's very hard to diagnose when, where and why they went
wrong. If the endpoints always sent a reINVITE (or UPDATE) when
concluding ICE,
even if they used the default candidates, this diagnosis of failures
would be
much easier.
Examples noted by the participants:
* Without a mandatory conclusion, is not possible to know how long
it took until end-points had successful media path established
* Without a mandatory conclusion, is not always possible to know if
different than default candidates have been chosen as lack of INVITE
does not tell deterministically what happened
* Without a mandatory conclusion, it is not possible for the callee
to restart ICE if it does not agree with the conclusion
We successfully exercised endpoints setting up and managing multiple
outbound
flows through separate edge proxies to a proxy/registrar (with different
implementations taking turns in the proxy registrar role). We forced the
network to break the flow in use in each case, verifying that subsequent
dialog-forming requests would take an alternate flow. We discovered an issue
with the recommendation in 5626 to have edge proxies record-route that
prevents
subsequent in-dialog requests from using alternate flows.
** SRTP
All implementations supported SDES for SRTP key exchange.
Good interop with many different combinations of endpoints.
Some calls were left up for an extended period so that sequence number
wrapping and roc increments were tested. Once the roc had changed the
call was put on hold and resumed with success. In this situation new RTP
streams with different SSRCs were created and the sequence number/roc
combination re-generated thus proving that support for multiple SRTP
contexts exists.
Debate surrounding how to signal 'best-effort crypto' continues. Some
implementations choose to advertise RTP/AVP with a=crypto attributes and
then go crypto if answer also has them and non-crypto if they do not.
RTP/SAVP is used to signal the desire for mandatory crypto. Another
approach observed was to repeat the same media line twice, once for
crypto and once for non-crypto and rely on the receiving end to only
accept one of them and port reject the other. In this case both m-lines
had the same port number and payload number descriptions so if a
receiving end accepted both then the originator would have no clue as to
whether it was receiving crypto or non-crypto traffic.
** Unusual messages
We tried several kinds of valid, but unusual messages.
Very few implementations did the right thing with a request-URI with an
unknown scheme - some phones would answer an INVITE with that in the
request-URI.
** Specification questions / comments
RFC 3263 currently says "If no SRV records are found, the client SHOULD
use TCP
for a SIPS URI" - it should probably say TLS over TCP.
In the spirit of Happy Eyeballs, there should be some guidance on what
to do when
the RFC 3263 process results in both A and AAAA records and the client
is capable
of using both.
There were implementations of SIP over DTLS, but the specification of
that usage
seems not to have completed.
There were questions on whether internationalized domain names could be
used in SIP URIs.
For use of SDP with ICE, there was an argument about whether a=rtcp was
mandatory if rtcp
was on the next port up. RFC 5245 says "If the agent is utilizing RTCP,
it MUST encode
the RTCP candidate using the a=rtcp attribute as defined in RFC 3605
[RFC3605].", and 3605 says "when that port is not the next higher
(odd) port number
following the RTP port described in the media line" to motivate why
the attribute was
created to begin with. Any updates to 5245 should clarify that adding
the a=rtcp attribute
is not optional when RTCP is being sent on the next higher port.
_______________________________________________
RAI mailing list
RAI(a)ietf.org
https://www.ietf.org/mailman/listinfo/rai
