sr-users April 2020

sr-users@lists.kamailio.org

70 participants
95 discussions

Query on force_send_socket
by Amarnath K 03 Apr '20

03 Apr '20

Hi All, I'm using Kamailio version 5.1.9. In cfg file have routing to send out SIP messages from Kamailio stack. In this routing logic added force_send_socket("tcp:192.168.40.10:5060"); forward() I'm expecting the send port should be from 5060, but it always pick random port to send out message. my requirement is to send SIP messages from 5060 port instead of picking random port. Regards, Amarnath

5 6

Kamailio release
by Virgílio Cunha 03 Apr '20

03 Apr '20

Hi, When is the scheduled release date of kamailio-5.3.4? Best Regards, Virgílio Cunha

1 0

[ot] lightweight sip app for auto-answering with play file and echo mode
by Daniel-Constantin Mierla 01 Apr '20

01 Apr '20

Hello, wondering if anyone here is aware of a lightweight sip app that can answer a call, play some file and/or do echo mode, mainly targeted at using it for basic sip routing and call testing. Of course I know that Asterisk and FreeSwitch (or even SEMS) can do that, but they have many dependencies, requiring quite some resources to run them, so I thought maybe someone here figured out different solutions, eventually cli based apps like pjsua or baresip. GUI apps for Linux are also fine if they can be configured for such behaviour. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

7 18

Invite transaction lifetime
by Duarte Rocha 01 Apr '20

01 Apr '20

Greetings, I have a strange call with a client in which he sends me an INVITE and i do the usual "100", "183" and "200 - OK" but the client never gets my provisional or final responses and, as such keeps retransmitting the first INVITE. For the first retransmissions Kamailio doesn't relay the INVITE which i think is the correct behaviour. However, after around 30s, a retransmission is processed and is relayed to a different destination, using "ds_select_dst()" from the DISPATCH module. For this to happen it had to fail the "t_check_trans()" function from TM module which tells me that the transaction from the first INVITE was gone. I went to search timers and lifetime definitions on TM module and found one "max_inv_lifetime" which tells me that "An INVITE transaction will be kept in memory for maximum: max_inv_lifetime+fr_timer(from the ACK to the final reply wait)+wt_timer". In this case : max_inv_lifetime is 180 seconds, fr_timer is 30 seconds and wt_timer is 5 seconds. It's sum is 215seconds and from what i can see, my transaction only had a lifetime of 30s. fr_timer is configured with 30s but it's definition is "Timer which hits if no final reply for a request or ACK for a negative INVITE reply arrives (in milliseconds)." and it mentions ACK, but in my case it's an ACK for a final reply that is missing and not an ACK for a negative reply. What other reasons might have caused this transaction to be terminated ? Best Regards

1 0

Re: [SR-Users] Use topos module to hide contact in OPTIONS request
by Enzo 01 Apr '20

01 Apr '20

2 1

2025

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 April 2020