sr-users August 2017

sr-users@lists.kamailio.org

89 participants
144 discussions

Kamailio failover - dialog (transaction) that is available on different proxies

by Donat Zenichev

Hi. I came up with idea to set up stand with two kamailio and one b2bua server (for routing). The idea consists of failover for dialogs, transactions. So if one of kamailio nodes is down, another one is able to catch up the dialog and let users to properly end up the session. For better realizing of it, I will try to describe the idea step by step: 1. UAC invites UAS, they've done three-way-handshake, media stream is up. 2. Kamailio that processed this dialog is down. 3. Users decided to end the session with BYE method, but proxy that processed their three-way-handshake recently is down, so one of ua sends BYE to the destination route that contains domain name (that both kamailio serve), BYE achieves the second kamailio to let him properly end the dialog. But, there is a big but, this second kamailio hasn't ever known about this dialog, he doesn't support any transactions for it and furthermore he doesn't know anything about this call-id. So the solution for it, as I think, is hidden in db mode for user location (columns that contain call-ids, branches etc. But I need to be sure, if I'm on the right way. For purpose, where one ip is served by two nodes, I have two solutions: -First one. I want to create heartbeat cluster with two kamailio nodes, they will have one shared ip address, so when one node gets down, another one brings up shared ip interface and implements the same actions that master does. -Another method is to assign a few ip addresses to one domain name (ip addresses of different kamailio proxies). So the goal looks simple, if someone has ever done something like that, I will be glad to read the ideas. -- -- BR, Donat Zenichev Wnet VoIP team Tel: +380(44) 5-900-808 http://wnet.ua

6 years, 7 months

Simultaneous calls in kamailio

by Logeshwaran G

Hi, Is there any way(tools) to place Simultaneous Calls in kamailio: For Example: 1000 calls simultaneously in Kamailio. Input Please?? Thanks & Kind Regards, Logeshwaran G

6 years, 7 months

Fwd: sdp extra \r\n in multipart body

by Diego Nadares

Hi Daniel! Thanks for your reply. The rtpengine module I think it's expecting two \r\n like: ...pcma/8000\r\n \r\n --uniqueboundary .... cpc,9\r\n \r\n --uniqueboundary-- I saw the code and I modified it but Can any one cofirm if multipart has to be like ...pcma/8000\r\n \r\n --uniqueboundary Or ...pcma/8000\r\n --uniqueboundary Or any one of those? Thanks again! Diego El El lun, 21 de ago. de 2017 a las 02:33, Daniel-Constantin Mierla < miconda(a)gmail.com> escribió: > Hello, > > there is \r\n after > > a=rtpmap:8 PCMA/8000 > > because > > --uniqueBoundary-- > > is on next line. > > Maybe is the fault of the code extracting sdp from multi-part body. Open > an issue on github bug tracker not to forget about it. If nobody looks at > it, I will try to do it, but it may take few days given traveling. > > Cheers, > Daniel > > On 18.08.17 22:21, Diego Nadares wrote: > > Hi guys, > > I have the following multipart body > > Content-Type: multipart/mixed;boundary=uniqueBoundary > Remote-Party-ID: <tel:1112222;phone-context=+54> > <1112222;phone-context=+54> > Content-Length: 364 > > --uniqueBoundary > Content-Type: application/sdp > > v=0 > o=user1 53655765 2353687637 IN IP4 111.111.111.111 > s=- > c=IN IP4 111.111.111.111 > t=0 0 > m=audio 6000 RTP/AVP 8 > *a=rtpmap:8 PCMA/8000* > *--uniqueBoundary--* > Content-Type: application/gtd > Content-Disposition: signal;handling=optional > > IAM, > CPC,20 > GCI,885sdfasdf1123 > > --uniqueBoundary-- > > > As you can see *--uniqueBoundary *before *a=rtpmap:8 PCMA/8000* has not > an extra '\r\n'. Is this correct? Or should have it? > > The thing is that rtpengine is receiving sdp with no final '\r'n' from > kamailio: > > Dump for 'offer' from 127.0.0.1:37388: { "sdp": "v=0#015#012o=user1 > 53655765 2353687637 IN IP4 111.111.111.111#015#012s=-#015#012c=IN IP4 > 111.111.111.111#015#012t=0 0#015#012m=audio 6000 RTP/AVP 8#015#012*a=rtpmap:8 > PCMA/8000"*, "ICE": "remove", "direction": [ "pub", "priv" ], "replace": > [ "origin", "session-connection" ], "transport-protocol": "RTP/AVP", > "call-id": "1-17755(a)111.111.111.111", "received-from": [ "IP4", > "111.111.111.111" ], "from-tag": "1", "command": "offer" } > > And the resulting sdp from rtpengine is this: > > --uniqueBoundary > Content-Type: application/sdp > > v=0 > o=user1 53655765 2353687637 IN IP4 172.16.213.16 > s=- > c=IN IP4 172.16.213.16 > t=0 0 > m=audio 35066 RTP/AVP 8 > *a=rtpmap:8 PCMA/8000a=sendrecv* > a=rtcp:35067 > > The problem is related with that '\r\n' but Is this a malformed message or > a possible bug? > > Thanks in advance! > > Diego > > > > > > > _______________________________________________ > Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training - www.asipto.com > Kamailio World Conference - www.kamailioworld.com > >

6 years, 7 months

Query in LCR Rule Target Table:

by Logeshwaran G

Hi, I need to know What is the Purpose of Priority and Weight column in Lcr_rule_target table: Example: | id | lcr_id | rule_id | gw_id | priority | weight | status | createdBy | createdDate | modifiedBy | modifiedDate | +----+--------+---------+-------+----------+--------+--------+-----------+-------------+------------+--------------+ | 1 | 1 | 1 | 1 | 1 | 1 | 1 | NULL | NULL | NULL | NULL | | 2 | 1 | 4 | 1 | 1 | 2 | 1 | NULL | NULL | NULL | NULL Kindly someone please Guide me. Thanks & Kind Regards, Logeshwaran G

6 years, 7 months

LCR dont_strip_or_prefix_flag

by Patrick Wakano

Hello list, I am using Kamailio 5.0.2 on centos7 and I am trying to use the dont_strip_or_prefix_flag ( https://www.kamailio.org/docs/modules/5.0.x/modules/lcr.html#idp49131644) for LCR routing but I discovered that just by declaring the flag like this the module won't prefix my calls: #!define LCR_DONT_STRIP_OR_TAG 7 modparam("lcr", "dont_strip_or_prefix_flag", LCR_DONT_STRIP_OR_TAG) It doesn't matter if I set or reset the flag it never prefix the ReqUR if the declaration is present. I have to remove the declaration to make the module prefix it correctly. But then the whole purpose of the flag is lost....Anyone aware of this behaviour? Regards, Patrick Wakano

6 years, 8 months

TSILO + NAT issues

by Emanuele Gambaro

Hi to all. I have the following setup-needs : *) Kamailio 5.0.1 with TSILO module and Apple push notification service. *) Rtpengine configured in order to force a "media-handover” for every call. *) NAT forced for all connection. I have a lot of problem with the INVRESUME route. When an INVITE is resumed (upon mobile client connection via APN message) the NAT does not work, and there is no rtp flow between devices. It works only if device is already online (so without the SUSPEND route). How can I setup TSILO in order to force NAT management for all calls? Thank you -- Emanuele Gambaro --- email: emanuele.gambaro(a)pynlab.com skype: sarbyn_work OpenPGP Key: https://goo.gl/fdeVnI

6 years, 8 months

lcr gws

by Logeshwaran G

Hi, I am having two lcr gateways in lcr_gw table. But When executing the "kamcmd lcr.dump_gws", Its showing only one gateway list: [root@zeodialer ~]# kamcmd lcr.dump_gws { lcr_id: 1 gw_id: 1 gw_index: 1 gw_name: Carrier1 scheme: sip: ip_addr: 104.251.178.29 hostname: port: 5060 params: transport: ;transport=udp strip: 0 prefix: tag: flags: 1 state: 0 defunct_until: 0 } Did I missing something? Thanks & Kind Regards, Logeshwaran G

6 years, 8 months

Fwd: Weird issue with kamailio relaying messages to itself

by George Diamantopoulos

Stupid gmail replying to sender only... ---------- Forwarded message ---------- From: George Diamantopoulos <georgediam(a)gmail.com> Date: 27 August 2017 at 02:29 Subject: Re: [SR-Users] Weird issue with kamailio relaying messages to itself To: Daniel-Constantin Mierla <miconda(a)gmail.com> Hello all, I've figured out what was going on, so I'm sharing here in case anyone else runs into this. I guess it should be a fairly common situation under certain circumstances when using the dispatcher module... The problem was that no destinations in the dispatcher set used were available for these requests. So $du was not set by ds_select_next. Which meant that when t_relay() was called later in the script, it would route based on R-URI, and the RURI's uri was kamailio itself. As to the reason why I was left with no dispatcher destinations available, well, I would mark destinations offline for 500 "server error" responses coming from them, and asterisk (which is the receiving application for all of dispatcher's destination sets) will send out a 500 to the B-leg when it receives a 480 to an A-leg. Getting a single 480 to one of the asterisk boxes would cause this to happen across all destinations, as kamailio would retry the next destination after a 500 failure and would receive a 500 from all of them in the end (because all of them would get the 480 in such small time frame). BR, George On 31 July 2017 at 21:52, George Diamantopoulos <georgediam(a)gmail.com> wrote: > Hello Daniel, > > Thanks for the reply. That is correct, looping was not my intention, I'm > trying to figure out what's causing it... > > BR, > George > > On 31 July 2017 at 17:29, Daniel-Constantin Mierla <miconda(a)gmail.com> > wrote: > >> Hello, >> >> usually you should not loop requests locally, unless a very special case >> -- do you do the loop routing because of a need or just happens but you >> don't know why? >> >> Cheers, >> Daniel >> >> On 31.07.17 13:46, George Diamantopoulos wrote: >> >> Hello all, >> >> I have been toying with kamailio lately, and I thought I had gotten to >> the point where I had a mostly working (tm) prototype. I gave it a test >> drive with some real calls, however, and an issue manifested at least once, >> where homer received packets originating from the kamailio host, and whose >> destination was also the kamailio host. >> >> The dialog this manifested in is a generally problematic one, with many >> retransmissions occurring because of slow database access (I haven't >> implemented htable caching yet). No packet capture over the network is >> actually taking place, I'm copying everything to homer with "trace_mode"set >> to 1. >> >> Homer shows these messages like in the screenshot: >> https://imagebin.ca/v/3VGJAmovRBmo. Here's an example of a packet: >> >> >> 2017-07-28 14:32:29 +0300 : 2.3.4.5:5060 -> 2.3.4.5:5060 >> INVITE sip:1234567890@kamailio-server.org SIP/2.0 >> Record-Route: <sip:2.3.4.5;lr;ftag=as491cec82> >> Via: SIP/2.0/UDP 2.3.4.5;branch=z9hG4bK0cf.0779 >> 9e3eb71f33a9ef91178ac760ebd2.0 >> Via: SIP/2.0/UDP 2.3.4.5;branch=z9hG4bKsr-BnCVy >> rWoUladI14pU7Pry-Pzy-ONy-VSQ74NU7HzeYazq2nFU2Oc5FIWiGIKq-HXe >> x1oONpam-C6IrIXkr4FQxZRh7sM >> Max-Forwards: 69 >> From: <sip:subscriber@5.4.3.2:5061>;tag=as491cec82 >> To: <sip:1234567890@kamailio-server.org> >> Contact: <sip:2.3.4.5;line=sr-eNC05xhKefQnON1EglFrOkF0OfpzV2s9UzM9UXM >> NQXMn5-B0Q-s*> >> Call-ID: 4e5d22c3369704b97d866c8d0f3798f8@192.168.201.2:5061 >> CSeq: 103 INVITE >> User-Agent: Asterisk PBX 11.13.1~dfsg-2~bpo70+1 >> Date: Fri, 28 Jul 2017 11:32:24 GMT >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, >> PUBLISH, MESSAGE >> Supported: replaces, timer >> Remote-Party-ID: "9876543210" <sip:9876543210@192.168.201.2> >> ;party=calling;privacy=off;screen=yes >> Content-Type: application/sdp >> Content-Length: 500 >> >> v=0 >> o=root 242468242 242468243 IN IP4 172.17.130.13 >> s=Asterisk PBX 11.13.1~dfsg-2~bpo70+1 >> c=IN IP4 172.17.130.13 >> t=0 0 >> m=audio 59426 RTP/AVP 18 101 >> a=rtpmap:18 G729/8000 >> a=fmtp:18 annexb=no >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-16 >> a=ptime:50 >> a=sendrecv >> a=rtcp:59427 >> a=ice-ufrag:hffIoy6x >> a=ice-pwd:nXB8ip7Qz8ZG5yyZRr97kGJbej >> a=candidate:igct4zWHEzhGCjWc 1 UDP 2130706431 <21%203070%206431> >> 172.17.130.13 59426 typ host >> a=candidate:igct4zWHEzhGCjWc 2 UDP 2130706430 <21%203070%206430> >> 172.17.130.13 59427 typ host >> >> Can something like this be triggered by misconfiguration in the routing >> scripts? Should it worry me and should I dig into it more? Could it be a >> bug of the siptrace module and nothing bad actually took place? I'm not >> sure where to start with this, so any input would be greatly appreciated. >> Thanks! >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> -- >> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda >> Kamailio Advanced Training - www.asipto.com >> Kamailio World Conference - www.kamailioworld.com >> >> >

6 years, 8 months

Kamailio fails to process ACK to 487 from Cisco-SIPGateway/IOS-12.x?

by George Diamantopoulos

Hello all, I'm having a weird issue with Kamailio failing to properly process an ACK received to a 487 it sent, resulting in retransmissions of the 487. I assume it's because it can't match the ACK to the transaction, but I could be wrong. I'm using a modified version of the default configuration, so ACKs should be handled correctly. I haven't editted the WITHINDLG route in any way that would affect this (or at least I think). In addition, ACKs to 487 from other UAs are processed correctly, and these transactions are handled by the same routes in kamailio configuration as the problematic one, so I'm inclined to believe it's UA-specific? Here's an example transaction of the failed kind (results in kamailio retransmitting the 487): myself:5060 -> peer:5060 ------------------------- SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP peer:5060 From: <sip:user@peer>;tag=116B5368-24D8 To: <sip:tel@myself>;tag=as655f6372 Call-ID: 84DC69F2-873811E7-8A639B5A-3D9194E8@peer CSeq: 101 INVITE Server: modCOM v2 SIP Server Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Length: 0 peer:49590 -> myself:5060 ------------------------- ACK sip:tel@myself:5060 SIP/2.0 Via: SIP/2.0/UDP peer:5060 From: <sip:user@peer>;tag=116B5368-24D8 To: <sip:tel@myself>;tag=as655f6372 Date: Wed, 23 Aug 2017 12:50:47 GMT Call-ID: 84DC69F2-873811E7-8A639B5A-3D9194E8@peer Max-Forwards: 10 Content-Length: 0 CSeq: 101 ACK And here's another similar transaction which is successful (no retransmissions): myself:5060 -> peer:5060 ------------------------ SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP peer:5060;branch=z9hG4bKjbmvq4009gthskk0a6s1.1 From: <sip:user@anonymous.invalid;user=phone>;tag=599D7495-9ACE9E3-0A324A05 To: <sip:tel@anonymous.invalid:5060;user=phone>;tag=as65375e5d Call-ID: 599D7495-007A5832@fath3pcu238 CSeq: 1 INVITE Server: modCOM v2 SIP Server Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Length: 0 peer:5060 -> myself:5060 ------------------------ ACK sip:tel@myself:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP peer:5060;branch=z9hG4bKjbmvq4009gthskk0a6s1.1 From: <sip:user@anonymous.invalid;user=phone>;tag=599D7495-9ACE9E3-0A324A05 To: <sip:tel@anonymous.invalid:5060;user=phone>;tag=as65375e5d Call-ID: 599D7495-007A5832@fath3pcu238 Max-Forwards: 69 Content-Length: 0 CSeq: 1 ACK I can't pinpoint anything wrong with the first exchange, other than the fact that for some reason, the "less than" (<) sign in the from and to URIs is escaped as &lt in homer's GUI (which also breaks CSS rendering in Firefox, I had to clear this code out). However, these escaping characters are not visible with sngrep when capturing traffic normally, and neither when doing a select in homer's database directly, so I guess it's a rendering bug in homer-ui and can be ignored (unless someone has reason to believe otherwise). Now the relevant portion of the debug log is: Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) exec: *** cfgtrace:request_route=[WITHINDLG] c=[/etc/kamailio/kamailio.cfg] l=223 a=24 n=t_check_trans Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:1001]: t_check_msg(): msg id=104 global id=103 T start=(nil) Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:459]: t_lookup_request(): start searching: hash=54992, isACK=1 Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:494]: t_lookup_request(): proceeding to pre-RFC3261 transaction matching Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:641]: t_lookup_request(): no transaction found Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:1070]: t_check_msg(): msg id=104 global id=104 T end=(nil) Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) exec: *** cfgtrace:request_route=[WITHINDLG] c=[/etc/kamailio/kamailio.cfg] l=231 a=2 n=exit It explicitly states that no transaction is found, after initiating pre-RFC3261 (why?) transaction matching. However, even pre-3261 matching should work, as the from and to headers as well as call-id in request and repy are the same. Any input would be greatly appreciated, thanks! George

6 years, 8 months

One Kamailio and many RTPENGINEs

by Denys Pozniak

Hello! I want to build distributed topology with one KAMAILIO and 5x RTPENGINEs for each region. I will have dedicated links between these sites, so I can garantee somehow voice quality. If one customer from region1 calls customer region2, RTP should go: Customer1->RTEPNGINE1->RTPENGINE2->Customer2 So the main question: Can one Kamailio build "call" between two RTPENGINEs ? BR, Denys

6 years, 8 months

← Newer
1
2
3
4
5
6
7
...
15
Older →

Jump to page:

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 2017