sr-dev

sr-dev@lists.kamailio.org

44307 discussions

SF.net SVN: openser:[5977] branches/1.4/Makefile.defs

by Daniel-Constantin Mierla

Revision: 5977 http://openser.svn.sourceforge.net/openser/?rev=5977&view=rev Author: miconda Date: 2010-02-02 19:20:08 +0000 (Tue, 02 Feb 2010) Log Message: ----------- - version set to 1.4.5 Modified Paths: -------------- branches/1.4/Makefile.defs This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

14 years, 12 months

SF.net SVN: openser:[5976] branches/1.5/Makefile.defs

by Daniel-Constantin Mierla

Revision: 5976 http://openser.svn.sourceforge.net/openser/?rev=5976&view=rev Author: miconda Date: 2010-02-02 19:18:12 +0000 (Tue, 02 Feb 2010) Log Message: ----------- - version set to 1.5.3 Modified Paths: -------------- branches/1.5/Makefile.defs This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

14 years, 12 months

[tracker] Task opened: 1.5.3 dialog module: dialogs stay in database when in "shutdown only" mode

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Nathan Angelacos (nangelacos) Attached to Project - sip-router Summary - 1.5.3 dialog module: dialogs stay in database when in "shutdown only" mode Task Type - Bug Report Category - Module Status - Unconfirmed Assigned To - Operating System - Linux Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - As reported in: http://lists.kamailio.org/pipermail/users/2009-December/025782.html dialogs are not deleted from the database table on startup when in "shutdown only" mode. The dialog db table then contains stale data that is reloaded the next restart More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=36 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 12 months

preparing kamailio 1.5.4 and 1.4.5 releases

by Daniel-Constantin Mierla

Hello, soon I will start preparing the 1.5.4 and 1.4.5. The only issue reported and not clarified yet is the tcp failover that I tried to reproduce today without luck, might be dependent of (triggered faster on) particular architecture. It can be fixed once gathering more details or being able to reproduce. If you are aware of something else, please report to devel list. 1.4.5 will mark the official support for 1.4.x series, although some fixes may go back there from time to time, but I don't think will be another release of that branch. I recommend to update to newer version or stick to svn for updates. Cheers, Daniel -- Daniel-Constantin Mierla eLearning class for Kamailio 3.0.0 Starting Feb 8, 2010 * http://www.asipto.com/

14 years, 12 months

kamailio 1.5 rev 5868: transaction not released when receiving 400

by Iñaki Baz Castillo

Hi, using kamailio 1.5 rev 5868 (2009-06-02) I'm experimenting a strange issue: - Kamailio relays (t_relay) an INVITE to a gateway. - The gateway replies 400 due to local access policy (don't ask me why it decides to use 400 code). - Kamailio sends the ACK and routes back the 400 upstream correctly, but it shows a warning "transaction not released" (or a similar text). It makes no sense as there is not especial handling for 400 responses, and the warning doesn't occur when receiving any other final non 2XX code. However I've haven't tested with new versions, I just would like to know if it's a known issue. Thanks. -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 12 months

SF.net SVN: openser:[5975] branches/1.4/ChangeLog

by Henning Westerholt

Revision: 5975 http://openser.svn.sourceforge.net/openser/?rev=5975&view=rev Author: henningw Date: 2010-02-02 17:01:26 +0000 (Tue, 02 Feb 2010) Log Message: ----------- * update Changelog Modified Paths: -------------- branches/1.4/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

14 years, 12 months

SF.net SVN: openser:[5974] branches/1.4/doc/authors.xml

by Henning Westerholt

Revision: 5974 http://openser.svn.sourceforge.net/openser/?rev=5974&view=rev Author: henningw Date: 2010-02-02 16:57:52 +0000 (Tue, 02 Feb 2010) Log Message: ----------- * update author.xml file from 1.5 state Modified Paths: -------------- branches/1.4/doc/authors.xml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

14 years, 12 months

SF.net SVN: openser:[5973] branches/1.5/ChangeLog

by Henning Westerholt

Revision: 5973 http://openser.svn.sourceforge.net/openser/?rev=5973&view=rev Author: henningw Date: 2010-02-02 16:52:14 +0000 (Tue, 02 Feb 2010) Log Message: ----------- * update Changelog Modified Paths: -------------- branches/1.5/ChangeLog This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

14 years, 12 months

Suggestion: Common Log file for Sip-Router / Kamailio

by Iñaki Baz Castillo

Hi, in most of my deployments I see myself adding xlog lines to imitate an "access" log (like Apache/Nginx/Squid do). Note that this is not the same as a CDR. Also, using xlog for this purpose is not very cool as the logs are mixed with other logs generated by SR/Kamailio itself (or its modules) as warnings, errors, other custom xlog's... I'm reading a draft called "The Common Log File (CLF) format for SIP": http://tools.ietf.org/html/draft-gurbani-sipping-clf It seems really interesting for me and I'd love to have something similar in SR/Kamailio. The only "similar" approach would be using the siptrace module storing all the SIP flows into database, however it's not recommended for scenarios with high traffic. An example of this kind of log would be the following (extracted from the draft): - Alice calls Bob. - The proxy does parallel forking to two locations. - Bob-1 replies 500. - Bob-2 replies 200. - Alice sends the ACK for the 200. The common log generated by the proxy would look as follows: ------------------------------------------------------------------------ ### Received request (server transaction): 1230756560 192.168.1.10 - INVITE sip:bob@example.net sip:alice@example.com;tag=hy7 sip:bob@example.net 7yhgt1(a)example.com - uyt67h FORK/- ### 100 replied upstream: 1230756560 uyt67h - 100 INVITE + - # First INVITE generated by the proxy (client transaction): 1230756563 - - INVITE sip:bob@home.example.net sip:alice@example.com;tag=hy7 sip:bob@example.net 7yhgt1(a)example.com - uyt67h CLIENT/hb76 ### Second INVITE generated by the proxy (client transaction): 1230756564 - - INVITE sip:bob@carphone.example.net sip:alice@example.com;tag=hy7 sip:bob@example.net 7yhgt1(a)example.com - uyt67h CLIENT/hb77 ### Replies received from Bob-1 and Bob-2: 1230756565 uyt67h hb76 100 INVITE sip:bob@example.net;tag=876v - 1230756565 uyt67h hb77 100 INVITE sip:bob@example.net;tag=561t - 1230756565 uyt67h hb76 180 INVITE sip:bob@example.net;tag=876v - 1230756565 uyt67h hb77 180 INVITE sip:bob@example.net;tag=561t - 1230756567 uyt67h hb77 182 INVITE sip:bob@example.net;tag=561t - 1230756568 uyt67h hb76 500 INVITE sip:bob@example.net;tag=876v - 1230756568 uyt67h hb77 200 INVITE sip:bob@example.net;tag=561t "sip:bob@home.example.net" ### 200 replied upstream: 1230756569 uyt67h - 200 INVITE sip:bob@example.net;tag=561t "sip:bob@home.example.net" ### ACK sent to Bob-1 to acknoledge the 500 response: 1230756569 + - ACK sip:bob@home.example.net + + + - uyt67h CLIENT/hb76 ### ACK received by the proxy and relayed to Bob-2: 1230756570 192.168.1.10 - ACK sip:bob@home.example.net sip:alice@example.com;tag=hy7 sip:bob@example.net;tag=76y 7yhgt1(a)example.com - t6y5 FORK/- 1230756570 - - ACK sip:bob@home.example.net sip:alice@example.com;tag=hy7 sip:bob@example.net;tag=76y 7yhgt1(a)example.com - t6y5 CLIENT/hb89 ------------------------------------------------------------------------ Would make sense a SR module to achieve this purpose? Such module should write these logs into a file (not syslog). Regards. -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 12 months

git:master: core: fix bogus gcc-4.4 warning

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: 3a99415a7df46e2fd63698ee407c5075aac01846 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=3a99415… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Tue Feb 2 17:40:22 2010 +0100 core: fix bogus gcc-4.4 warning --- ip_addr.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ip_addr.h b/ip_addr.h index 2983e46..4f027ec 100644 --- a/ip_addr.h +++ b/ip_addr.h @@ -696,7 +696,7 @@ static inline char* su2a(union sockaddr_union* su, int su_len) if (unlikely(su_len<sizeof(su->sin6))) return "<addr. error>"; buf[0]='['; - offs=1+ip6tosbuf((unsigned char*)&su->sin6.sin6_addr, &buf[1], + offs=1+ip6tosbuf((unsigned char*)su->sin6.sin6_addr.s6_addr, &buf[1], sizeof(buf)-4); buf[offs]=']'; offs++;

14 years, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev