sr-users July 2009

sr-users@lists.kamailio.org

71 participants
104 discussions

by zhangchao00001

Dear sir: I write to ask if the kamailio support multi-domain. for example, A UA belong to domain b get into domain a, could it work as well as in domain b? If so, how to configure it? Thank you.

14 years, 10 months

force_rtp_proxy() vis-a-vis BYE

by Alex Balashov

According to the Kamailio 1.5.x docs, force_rtp_proxy() is deprecated and rtpproxy_offer() and rtpproxy_answer() should be used instead. Does that mean unforce_rtp_proxy() is also deprecated? If so, how should calls be cleaned up once a BYE is received? Is the orthodox approach to simply let the streams time out on their own, or should unforce_rtp_proxy() still be used here? What about when a CANCEL is received while the dialog is an early state -- should unforce_rtp_proxy() be used there too? Thanks! -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775

14 years, 10 months

[Serusers] SER generating Via: with branch parameter equal to "0" over half the time

by Frank Durda IV

A telco equipment vendor has pointed out that when an ACK message pass via our SER servers, a Via: header is added which is normal, but frequently the branch value in that Via: header is "0". As in: Via: SIP/2.0/UDP 10.133.90.x;branch=0 This violates RFC 3261 for being zero and for not being "unique across time and space". (8.1.1.7, page 38). This is showing up in over 50% of the ACK messages being passed through in just one direction. When not equal to zero, the value is like this: Via: SIP/2.0/UDP 10.133.90.x;branch=z9hG4bK095a.b27ac307.0 We don't see branch=0 appearing in any other SIP message type, just ACKs. Is anybody else seeing this and perhaps have a fix? The telco equipment vendor doesn't think it is confusing their equipment, but as it is out spec they want to eliminate it as a source of trouble. The calls are originating in a variety of types of equipment including Acme, Sonus, Asterisk, etc. This is the Via: added by SER, any already present when we got the call are non-zero and look fine. We are running ser-2.0.0-rc1. A sample: ACK sip:6x0x9x0x0x;npdi=yes;rn=6x0x6x9x7x@10.133.0.x:5060 SIP/2.0 Via: SIP/2.0/UDP 10.1x3.9x.1x;branch=0 Via: SIP/2.0/UDP 7x.1x.1x3.1x0:5060;branch=z9hG4bK02Bd8a36ba5a45d76d6 From: <sip:Restricted@7x.1x.1x3.1x0>;tag=gK020a4ae7 To: <sip:6103900202@2x8.3x.2x1.7x>;tag=000a0285+1+11540020+75d5539b Call-ID: 2097284613_75974428(a)7x.1x.1x3.1x0 CSeq: 15498 ACK Max-Forwards: 16 Content-Length: 0 Thanks in advance.

14 years, 10 months

[Kamailio-Users] irc devel meeting

by Daniel-Constantin Mierla

Hello, within K project, we had from time to time an IRC meeting for short term planning. IMO it is the time for next one since probably we need at least a kamailio 1.5.2 release. The place was the irc channel #kamailio on freenode.net, now we can host it on #sip-router. Presence is not mandatory and anyone is welcome to join. From the perspective of K project, here are the topics I would like to approach: - kamailio 1.5.2 - show-stoppers, when? - shall we do another branch 1.4-based release - kamailio 3.0 - current status - what is missing, what can be worked-around, prioritizing tasks... - documentation - migration tutorials - release roadmap For sip router: - logistics: anything missing for project now? - what can be done to make adoption easier (new tools, etc...) - suggestions for future development I propose Tuesday, July 7, 2009, we can adjust to fit the best for the people that want to attend. I started a wiki page, feel free to add there: https://sip-router.org/wiki/devel/irc-meetings/2009-07-07 Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com/

14 years, 10 months

[Kamailio-Users] SEMS 1.1.1 released

by Stefan Sayer

(apologies if you receive multiple copies of this mail) Hello, the 111 version of SEMS, the SIP Express Media Server, is now available for download at http://ftp.iptel.org/pub/sems/1.1/1.1.1/ http://ftp.iptel.org/pub/sems/1.1/1.1.1/src/sems-1.1.1.tar.gz 4a6422d09ddadaf9eacd8cae8f0848d5 sems-1.1.1.tar.gz Debian packages for lenny64 are available in the repository: deb http://ftp.iptel.org/pub/sems/debian lenny free deb-src http://ftp.iptel.org/pub/sems/debian lenny free and etch64 in http://ftp.iptel.org/pub/sems/1.1/1.1.1/packages . This is a bugfix release in the 1.1 branch which accumulates fixes for bugs found in 1.1.0 so far. Specifically, this is - fixed Via HF missing the port number in ACK to 200 reply - do not try to scale too short RTP packets - fixed initialization of SSL - caused random crashing of xmlrpc server - fix size() for AmArg struct type - authenticate on both 401 and 407 reply in click2dial - fixed ssl build dependency for DIAMETER client in deb Many Thanks to everyone who contributed with bug reporting and fixes. More information, documentation etc about SEMS can be found at its homepage: http://iptel.org/sems Best Regards Stefan Sayer -- Stefan Sayer VoIP Services stefan.sayer(a)iptego.com www.iptego.com IPTEGO GmbH Wittenbergplatz 1 10789 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann

14 years, 10 months

[Kamailio-Users] force_rtp_proxy() vis-a-vis BYE

by Alex Balashov

According to the 1.5.x docs, force_rtp_proxy() is deprecated and rtpproxy_offer() and rtpproxy_answer() should be used instead. Does that mean unforce_rtp_proxy() is also deprecated? If so, how should calls be cleaned up once a BYE is received? Is the orthodox approach to simply let the streams time out on their own, or should unforce_rtp_proxy() still be used here? What about when a CANCEL is received while the dialog is an early state -- should unforce_rtp_proxy() be used there too? Thanks! -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775

14 years, 10 months

Images in the Document "SIP Introduction"

by Antônio Theóphilo

Hello Everybody Does anyone know how to get the images that are broken in the document "SIP Introduction" ( http://sip-router.org/docbook/sip-router/branch/master/sip/sip_introduction… )?It seems that they are diagrams very important for the understanding of the protocol's dynamics. Antônio Theóphilo

14 years, 10 months

[Kamailio-Users] SIP-Router Project - how does this affect me?

by Geoffrey Mina

I am not clear on what exactly the SIP-Router project is, nor how it will affect me? Is Kamailio eventually being replaced with SIP-Router once all the functionalities have been rolled in? Will my entire configuration script need to be reworked to eventually operate with this new platform? Can anyone explain to me why this merge is happening so soon after Kamailio split with OpenSIPS? All this turmoil feels very destructive to me.

14 years, 10 months

[Kamailio-Users] How should I change Calling Party Number for a call?

by Uriel Rozenbaum

Hi Guys, I was wondering how can I implement a proxy with Kamailio that can manage privacy and normalization of the calling party. In an INVITE message I can get the calling party name (or number) in several places: 1. From Header 2. Remote-Party ID 3. P-Asserted-Identity 4. P-Preferred-Identity How should I act in order to normalize or block the Calling Party to be passed to subsequent hops? AFAIK I can change the From Header as long as the tag isn't modified. Is this really true? What about RPID or PAI? Should I Change the aliases there as well? Thanks in advance to all! Uriel

14 years, 10 months

[Kamailio-Users] strange fr_inv_timer behaviour

by hans＠onsmail.nl

Hi, When setting fr_inv_timer to 60s and the phone is not answered kamailio generates a timeout after 20s ? If fr_inv_timer is set to 90s the timeout is generated after 30s ? Doing a level 7 debug I received the following tm timer related output Jun 3 15:07:12 sip-proxy-01 /usr/local/sbin/kamailio[1755]: DBG:tm:set_timer: relative timeout is 500000 Jun 3 15:07:12 sip-proxy-01 /usr/local/sbin/kamailio[1755]: DBG:tm:insert_timer_unsafe: [4]: 0xafa6abc4 (16900000) Jun 3 15:07:12 sip-proxy-01 /usr/local/sbin/kamailio[1755]: DBG:tm:set_timer: relative timeout is 3 Jun 3 15:07:12 sip-proxy-01 /usr/local/sbin/kamailio[1755]: DBG:tm:insert_timer_unsafe: [0]: 0xafa6abe0 (51) Jun 3 15:07:12 sip-proxy-01 /usr/local/sbin/kamailio[1754]: DBG:tm:set_timer: relative timeout is 60 Jun 3 15:07:12 sip-proxy-01 /usr/local/sbin/kamailio[1754]: DBG:tm:insert_timer_unsafe: [1]: 0xafa6abe0 (108) Jun 3 15:07:12 sip-proxy-01 /usr/local/sbin/kamailio[1751]: DBG:tm:set_timer: relative timeout is 60 Jun 3 15:07:12 sip-proxy-01 /usr/local/sbin/kamailio[1751]: DBG:tm:insert_timer_unsafe: [1]: 0xafa6abe0 (108) Jun 3 15:07:12 sip-proxy-01 /usr/local/sbin/kamailio[1758]: DBG:tm:utimer_routine: timer routine:4,tl=0xafa6abc4 next=(nil), timeout=16900000 <phone is ringing ....> Jun 3 15:07:32 sip-proxy-01 /usr/local/sbin/kamailio[1758]: DBG:tm:timer_routine: timer routine:1,tl=0xafa6abe0 next=(nil), timeout=108 Jun 3 15:07:32 sip-proxy-01 /usr/local/sbin/kamailio[1758]: DBG:tm:final_response_handler: stop retr. and send CANCEL (0xafa6aa78) Jun 3 15:07:32 sip-proxy-01 /usr/local/sbin/kamailio[1758]: DBG:tm:t_should_relay_response: T_code=180, new_code=408 Jun 3 15:07:32 sip-proxy-01 /usr/local/sbin/kamailio[1758]: DBG:tm:t_pick_branch: picked branch 0, code 408 Jun 3 15:07:32 sip-proxy-01 /usr/local/sbin/kamailio[1758]: DBG:tm:t_check: start=0xafa6aa78 Jun 3 15:07:32 sip-proxy-01 /usr/local/sbin/kamailio[1758]: DBG:tm:t_check: transaction already found! Jun 3 15:07:32 sip-proxy-01 /usr/local/sbin/kamailio[1758]: DBG:tm:pv_get_tm_reply_code: reply code is <408> version: kamailio 1.5.1-notls (i386/linux) flags: STATISTICS, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4194304 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: 2:5868M @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $ main.c compiled on 14:40:00 Jun 3 2009 with gcc 4.1.2 Kind regards Hans

14 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 July 2009