sr-users August 2023

sr-users@lists.kamailio.org

44 participants
43 discussions

by Anthony Blandin

Hello, I have a Kamailio SBC connected to another foreign SBC and to a media server. In case of non response, Kamailio SBC receives a 480 Temporarily not available from the foreign SBC and I need to forward this 480 to my media server but I don't see how to do that. The 480 arrives in the onreply_route. If I use then a failure_route, it resends the initial INVITE and not the 480. Is there a way to do that? Thanks for your help. Anthony Blandin

8 months, 1 week

Re: extreme dildoes

by Angel Elena

I think is better sip over tls to extra protection xD Sent from Android device El 26 ago 2023 12:59, Julien Chavanton <jchavanton(a)gmail.com> escribió: Are you trying to connect them over SIP ? On Sat, Aug 26, 2023, 6:06 AM <feigelwang(a)uusextoy.com <mailto:feigelwang@uusextoy.com> > wrote: So, when you still are alone, buying a huge dildo is worth it. Enjoy sex with the huge realistic dildo anytime and anywhere. Not only that, the big dildo brings completely different sexual stimulation. Maybe you want to enjoy full sex, should try some other sex toys. https://www.hugedildo.com/ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org> Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

8 months, 2 weeks

extreme dildoes

by feigelwang＠uusextoy.com

So, when you still are alone, buying a huge dildo is worth it. Enjoy sex with the huge realistic dildo anytime and anywhere. Not only that, the big dildo brings completely different sexual stimulation. Maybe you want to enjoy full sex, should try some other sex toys. https://www.hugedildo.com/

8 months, 2 weeks

large dildo

by feigelwang＠uusextoy.com

Or, if you are good at Google search, I believe you can definitely find more ways to play the big dildo. All in all, huge dildos are the best sex toy for singles. For single women, it’s vaginal masturbation. For single men, it’s anal sex. https://www.hugedildo.com/

8 months, 2 weeks

large dildo

by feigelwang＠uusextoy.com

8 months, 2 weeks

extreme dildoes

by feigelwang＠uusextoy.com

8 months, 2 weeks

rtpengine large number used RTP ports

by marek

hi, i have open around ~8000 rtp ports for around ~200calls (in peak) with this statistic (current data, not from peak) rtpengine_closed_sessions_total{reason="rejected"} 0 rtpengine_closed_sessions_total{reason="timeout"} 237405 rtpengine_closed_sessions_total{reason="silent_timeout"} 103 rtpengine_closed_sessions_total{reason="final_timeout"} 0 rtpengine_closed_sessions_total{reason="offer_timeout"} 0 rtpengine_closed_sessions_total{reason="terminated"} 0 rtpengine_request_seconds_total{proxy="127.0.0.1",request="offer"} 539.270967 rtpengine_request_seconds_total{proxy="127.0.0.1",request="answer"} 367.237641 rtpengine_request_seconds_total{proxy="127.0.0.1",request="delete"} 0.000000 is it normal? (large number of timeouts, "zero" terminated) or i have missing rtpengine_manage (rtpengine_delete) somewhere? (os rocky 9.2, kamailio 5.6.4, rtpengine 11.3.1) thanks Marek

8 months, 2 weeks

excessive CANCELs

by James Lipski

Hello, I've already suppressed this via routing logic, however I was wondering if there is a dedicated parameter that handles this. I'm currently running version 5.6.4. Scenario: UA-1 registered towards kamailio, calls UA-2 which is registered towards a different platform (non kamailio); so there are 2 proxys involved. kamailio is set to fork the call to voicemail if there is either no response completely from the other end, or the call goes unanswered. So the initial leg is: UA-1 <-----> kamailio <-----> second proxy <-----> UA-2 Issue: I'm trying to catch a case where the second proxy does issue a "100 Trying" for the initial INVITE; and then timesout. The call does fork to voicemail; however 14000+ SIP packets are generated between kamailio and the second proxy of CANCEL and "100 Trying" (the 100 Trying has a CSeq for INVITE still). Is there a way to suppress the amount of CANCELs that is transmitted in this situation? I'm using the following as my "tm" parameters: modparam("tm", "failure_reply_mode", 3) modparam("tm", "fr_timer", 30000) modparam("tm", "fr_inv_timer", 300000) modparam("tm", "auto_inv_100_reason", "Trying") Thanks. Example SIP trace: (UA-1 --> kamailio) 72.255.255.255 --> 10.64.52.110 INVITE sip:131@sip-example.com SIP/2.0 v: SIP/2.0/UDP 10.0.0.102:51519;branch=z9hG4bK-xfelmyyjzne5;rport f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Max-Forwards: 70 User-Agent: snomD785/10.1.152.12 m: <sip:133@10.0.0.102:51519;line=6dv00d6r>;reg-id=1 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, replaces, from-change Session-Expires: 3600 Min-SE: 90 Proxy-Authorization: Digest username="133",realm="sip-example.com",nonce="ZOTEBGTkwtiM22ZE8IJsn/esiW3CZrt0"[,uri="sip:131@sip-example.com](mailto:,uri=)",response="fb44b4fe0f8fb17de13f043cf1248e14",algorithm=MD5 c: application/sdp l: 309 v=0 o=root 481174289 481174289 IN IP4 10.0.0.102 s=call c=IN IP4 10.0.0.102 t=0 0 m=audio 50864 RTP/AVP 9 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv -------------------------------------------- (UA-1 <-- kamailio) 72.255.255.255 <-- 10.64.52.110 SIP/2.0 100 Trying v: SIP/2.0/UDP 10.0.0.102:51519;branch=z9hG4bK-xfelmyyjzne5;rport=51519;received=72.255.255.255 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Content-Length: 0 -------------------------------------------- (kamailio --> second proxy) 10.64.52.110 --> 10.64.52.100 INVITE sip:second-proxy-example.com:5066;ua=43a58ecca39c9c8f37515e55b5b37ed7 SIP/2.0 Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Max-Forwards: 15 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, replaces, from-change Session-Expires: 3600 Min-SE: 90 c: application/sdp l: 313 Contact: <sip:leg_1@sip-example.com;ccr=btpsh-64e387e0-ee528-2> v=0 o=root 481174289 481174289 IN IP4 10.64.52.111 s=call c=IN IP4 10.64.52.111 t=0 0 m=audio 34084 RTP/AVP 9 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv -------------------------------------------- (kamailio <-- second proxy) 10.64.52.110 <-- 10.64.52.100 SIP/2.0 100 Trying v: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE l: 0 -------------------------------------------- After 10 seconds of no further response from second proxy, call is forked to voicemail (kamailio --> voicemail) 10.64.52.110 --> 10.64.56.10 INVITE sip:voicemail@voicemail-example.com SIP/2.0 Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.1 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Max-Forwards: 15 Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE Allow-Events: talk, hold, refer, call-info Supported: timer, replaces, from-change Session-Expires: 3600 Min-SE: 90 c: application/sdp l: 313 Contact: <sip:leg_1@sip-example.com;ccr=btpsh-64e387e0-ee533-3> v=0 o=root 481174289 481174289 IN IP4 10.64.52.111 s=call c=IN IP4 10.64.52.111 t=0 0 m=audio 38722 RTP/AVP 9 0 8 18 101 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv -------------------------------------------- At roughly the same time, CANCEL is issued towards the second proxy (kamailio --> second proxy) 10.64.52.110 --> 10.64.52.100 CANCEL sip:second-proxy-example.com:5066;ua=43a58ecca39c9c8f37515e55b5b37ed7 SIP/2.0 Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com> i: 95c3e4642670-rx28v46dte4p CSeq: 1 CANCEL Max-Forwards: 15 l: 0 -------------------------------------------- (kamailio <-- voicemail) 10.64.52.110 <-- 10.64.56.10 SIP/2.0 200 Ok Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.1 From: <sip:133@sip-example.com>;tag=i4mlq4jr0y To: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>;tag=vzx5x3mlbd Call-ID: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Contact: <sip:voicemail@10.64.56.10:5078> Require: timer Session-Expires: 3600;refresher=uac Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Supported: timer, 100rel, replaces Content-Type: application/sdp Content-Length: 264 v=0 o=root 1084843702 1084843703 IN IP4 10.64.56.10 s=call c=IN IP4 10.64.56.10 t=0 0 m=audio 31908 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=alt:1 0.9 : user 9kksj== 10.64.56.10 31908 a=sendrecv -------------------------------------------- (UA-1 <-- kamailio) 72.255.255.255 <-- 10.64.52.110 SIP/2.0 200 Ok From: <sip:133@sip-example.com>;tag=i4mlq4jr0y To: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133>;tag=vzx5x3mlbd Call-ID: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE Require: timer Session-Expires: 3600;refresher=uac Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Supported: timer, 100rel, replaces Content-Type: application/sdp Content-Length: 270 Via: SIP/2.0/UDP 10.0.0.102:51519;received=72.255.255.255;branch=z9hG4bK-xfelmyyjzne5;rport=51519 Contact: <sip:leg_2@sip-example.com;ccr=atpsh-64e387e0-ee533-3> v=0 o=root 1084843702 1084843703 IN IP4 10.64.52.110 s=call c=IN IP4 10.64.52.110 t=0 0 m=audio 33552 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=alt:1 0.9 : user 9kksj== 10.64.56.10 31908 a=sendrecv =============================================== These next 2 SIP packets repeat, generating 14000+ CANCEL <--> 100 Trying transactions between kamailio, and the second proxy. (kamailio --> second proxy) 10.64.52.110 --> 10.64.52.100 CANCEL sip:second-proxy-example.com:5066;ua=43a58ecca39c9c8f37515e55b5b37ed7 SIP/2.0 Via: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com> i: 95c3e4642670-rx28v46dte4p CSeq: 1 CANCEL Max-Forwards: 15 l: 0 -------------------------------------------- (kamailio <-- second proxy) 10.64.52.110 <-- 10.64.52.100 SIP/2.0 100 Trying v: SIP/2.0/UDP 10.64.52.110:5060;branch=z9hG4bKecf9.6d10880e1353b8a7bbf0383d934a38a5.0 f: <sip:133@sip-example.com>;tag=i4mlq4jr0y t: <sip:131@sip-example.com?vm-ext%3D100%26ext-to%3D131%26ext-from%3D133> i: 95c3e4642670-rx28v46dte4p CSeq: 1 INVITE l: 0

8 months, 2 weeks

Force communications for I-CSCF and S-CSCF to be TCP only

by hvanhelmondt＠peratonlabs.com

Hi, I would like to force the transport protocol between the I-CSCF and S-CSCF to be TCP only. How would I do that exactly? I'm using an older Kamailio release 5.0.8. Regards,

8 months, 2 weeks

use_dns_failover default value

by Silvan Nagl

Hi, I would like to know the reason for having "off" as default value for use_dns_failover. https://github.com/kamailio/kamailio/issues/3547 Greetings, Silvan

8 months, 2 weeks

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 August 2023