sr-users October 2011

sr-users@lists.kamailio.org

69 participants
117 discussions

by Klaus Darilion

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

12 years, 10 months

current shm memory status

by Klaus Darilion

Hi! Is there a way to get the status of shm memory? (used memory vs. free memory) Thanks Klaus

12 years, 10 months

siremis: login error / http error 404

by Uwe Andersen

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

12 years, 10 months

Re: [SR-Users] uac module - error searching pvar "uac_req"

by Daniel-Constantin Mierla

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/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

12 years, 10 months

uac module - error searching pvar "uac_req"

by Vladimir Broz

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

12 years, 10 months

Re: [SR-Users] how to retrieve the contact username from 3xx reply?

by Uri Shacked

Thanks! works great.

12 years, 10 months

how to retrieve the contact username from 3xx reply?

by Uri Shacked

---------- 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?

12 years, 10 months

module docs broken

by Timo Reimann

Hey, documentation on the dialog module seems to be broken: The master branch directory content is empty http://sip-router.org/docbook/sip-router/branch/master/modules_k/dialog/ 3.1 shows close to nothing http://sip-router.org/docbook/sip-router/branch/3.1/modules_k/dialog/dialog… Moreover, 3.0 gives me 404 on the entire modules_k path: http://sip-router.org/docbook/sip-router/branch/3.0/modules_k/ Help. :) Cheers, --Timo

12 years, 10 months

T1 timer

by Vitaliy

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.

12 years, 10 months

Fwd: [RAI] SIPit 29 Summary

by Klaus Darilion

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

12 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users October 2011