- sr-users - kamailio.org

Kazoo module problem.
by Володимир Іванець 18 Dec '18

18 Dec '18

Hello! I'm trying to test kazoo module but unfortunately it is not loading: *0(25107) ERROR: <core> [core/sr_module.c:498]: load_module(): could not open module </usr/lib64/kamailio/modules/kazoo.so>: /usr/lib64/kamailio/modules/kazoo.so: undefined symbol: event_set* It was built today together with other modules and Kamailio itself today from branch 5.2 on CentOS 6. librabbitmq version is 0.5.2-1. Does anyone has it running and if so what version is it? Thanks a lot!

3 4

Access to tables like location, imc_rooms and imc_members when kamailio is running
by hamidreza ramezani 18 Dec '18

18 Dec '18

Hello everyone I have a question regarding kamailio database, I see when kamailio is stopped, usrloc -> location and imc -> imc_rooms module tables shows some information. but when kamailio is running it's not. is it possible to manually insert to these tables, I don't want to use IMC commands like #join #accept ... is it possible to access location table and see which users are registered when kamailio is running? Best regards Hamid

2 1

Routing of Audio and Video Stream.
by Abhijit Dutta 18 Dec '18

18 Dec '18

Hi All, Is it possible to redirect only the audio stream towards Asterisk from Kamailio (Proxy) via RTPEngine and not to send the video stream to Asterisk. I am yet to get the complete reason why my client wants this to happen though. Thanks Abhijit

5 12

Re: [SR-Users] Setup dmq_usrloc
by Gertjan Wolzak 17 Dec '18

17 Dec '18

Hello Kamailions, Reading and understanding is a skill in it self.. Learned a bit more of that this morning. To be able to use the dmq_ursloc, just use: if(is_method("KDMQ")) { dmq_handle_message(); } So, I have registrar replication working, on with reading to get the rest working. With regards, Gertjan

2 1

Setup dmq_usrloc
by Gertjan Wolzak 17 Dec '18

17 Dec '18

Hello Kamailions, Im trying to setup registration replication with the use of the dmq and dmq_usrlog modules. I have configured two servers, configured kamailio on both. When I register a sip client on the one I get a nice KDMQ message on the second server, but the second server reacts with a 404 not found: U 2018/12/17 05:08:38.974495 10.10.0.1:6000 -> 10.10.0.2:6000 #3 KDMQ sip:usrloc@10.10.0.2:6000 SIP/2.0. Via: SIP/2.0/UDP 10.10.0.1:6000;branch=z9hG4bK00ed.e1666b85000000000000000000000000.0. To: <sip:usrloc@10.10.0.2:6000>. From: <sip:usrloc@10.10.0.1:6000>;tag=a2652bb825a097f3b7285d4c70edd51a-0513. CSeq: 10 KDMQ. Call-ID: 35571d0247178282-3780(a)10.88.77.172. Content-Length: 360. User-Agent: kamailio (5.1.6 (x86_64/linux)). Max-Forwards: 1. Content-Type: application/json. . {"action":2,"aor":"test01(a)10.88.77.172","ruid":"uloc-5c177363-ec4-1","c":"sip:test01@10.88.77.140:59293;ob","received":"","path":"","callid":"zjucvmzUT2hNJCIfqeUXEsOaEzyHCs-4","user_agent":"CSipSimple_G3121-26/r2457","instance":"","expires":1545041786,"cseq":24435,"flags":0,"cflags":0,"q":-1,"last_modified":1545040886,"methods":8159,"reg_id":0,"server_id":0} U 2018/12/17 05:08:38.979062 10.10.0.2:6000 -> 10.10.0.1:6000 #4 SIP/2.0 404 Not Found. Via: SIP/2.0/UDP 10.10.0.1:6000;branch=z9hG4bK00ed.e1666b85000000000000000000000000.0;rport=6000. To: <sip:usrloc@10.10.0.2:6000>;tag=02f7a7b91eadf5e07797231cb2f64326-b794. From: <sip:usrloc@10.10.0.1:6000>;tag=a2652bb825a097f3b7285d4c70edd51a-0513. CSeq: 10 KDMQ. Call-ID: 35571d0247178282-3780(a)10.88.77.172. Server: kamailio (5.1.6 (x86_64/linux)). Content-Length: 0. . I think I have to configure a bit more than just the parameters of the dmq and dqm_usrloc modules. Ive googled, looked in the Sip routing with kamailio book, but no luck. Did not see any examples in the kamailio source, with regards to the dmq_usrloc module. I am not looking for direct answers, have not provided you with enough information for that, but I would appreciate information on how to correctly configure registration replication using the dmq/dmq_usrloc module... Thank you. With regards, Gertjan

1 0

Reminding again about private/direct emails from mailing lists discussions
by Daniel-Constantin Mierla 17 Dec '18

17 Dec '18

I see that still a lot of emails are sent directly to me after a discussion started on public mailing lists (subject with mailing lists prefix, but the sender header is not the mailing list daemon), I would like to remind that, at least in my case, writing emails directly without cc-ing the mailing list is highly not recommended and there is practically 0 chance to get an answer from myself. The rule is also suggested in the mailing lists presentation page: - https://www.kamailio.org/w/mailing-lists/ Unless I asked explicitly for a private email with some specific details, the message will not be noticed in decent time and therefore not replied. I use this email address for many public mailing lists and it is intended only for that usage, I am reacting based on the filters I created, unmatched messages getting the lowest priority. Therefore if you wrote me and expect a response, re-send the message to the appropriate public mailing list. Checking and answering the messages on Kamailio mailing lists are among the top of priorities on my daily activity, so it is high chance you get the response faster when you write there. Note that you can always mask sensitive data (e.g., replace passwords, IP addresses) before sending logs or config file. There are several common sense as well as technical reasons for keeping the discussion on public mailing lists. Here are some along with other suggestions to improve the likeliness of getting an answer: - we are not answering questions on mailing lists to help only one person, but also other people that may have similar issues in the future -- they can find the answers in the archive with a search engine. Also, other people subscribed to the list can learn from conversation or contribute to the discussion, resulting in better outcome - the amount of unexpected messages is very high -- it is practically a zero chance to get to the folder with messages that didn't match any filter (thus your message is not going to be replied) - whenever I find time, the first emails I answer are those coming on mailing lists. They are many there as well, people are traveling or having other personal or business projects, so sometime is good to send a reminder if a question does not get an answer - starting with negative approach or no technical content, like you are going to use something else if you don't get a reply instantly, or this application is missing what so ever tutorial giving exactly the solution you need, or simply asking for full config of complex requirements, is not helping at all, but actually making people to ignore your messages. Start with what you tried and where you got stuck. Everything you get is for free, have appropriate expectation and behavior. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

P-CSCF without Rx interface
by Tsvetan Filev 17 Dec '18

17 Dec '18

Hi All. May be this has been asked before but I was not able to find an answer. I setup IMS with 3 instances of kamailio: P-CSCF, I-CSCF and S-CSCF (I got the config files from here https://github.com/kamailio/kamailio/tree/master/misc/examples/ims). I would like to register two clients to the IMS and make a VoLTE like call. So I want to setup my P-CSCF to send SIP messages to my I-CSCF without Rx interface (without using PCRF). I'm not able to find how to tell P-CSCF where to direct the sip traffic. It obviously should happen in route[REGISTER]. Right now P-CSCF sends all REGISTER requests to itself and goes to a loop. Regards.

3 3

Sending to an announcement server from a failure_route
by Boden Garman 17 Dec '18

17 Dec '18

Hi list, I'm trying to play an announcement for my users when my PSTN gateway responds with a 404 Not Found (Reason: Q.850;cause=3), indicating a wrong number. I'm a bit lost and would appreciate any advice. What I am seeing is two parallel SIP invites, one to my announcement server (hooray!) and one to the PSTN gateway again (which I don't want). How do I stop the original branch from starting again? I've tried changing the order of rewritehostport and append_branch without any difference. I've also tried to use t_relay() instead of the RELAY route. I'm using Kamailio 5.1 and have modified the deafult kamailio.cfg Thanks! Boden I think this is the relevant parts of the config: # PSTN GW routing route[PSTN] { [PSTN regex logic omitted] # classify as an outbound call set_dlg_profile("outbound_calls"); # select a PSTN gateway from the dispatcher if (!ds_select_dst("66", "8")) { send_reply("404", "No destination"); exit; } # failover if the selected PSTN gateway is down t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } # Try next destinations in failure route failure_route[RTF_DISPATCH] { xlog("inside RTF_DISPATCH"); if (t_is_canceled()) { exit; } # wrong number from PSTN if (t_check_status("404")) { append_branch(); append_hf("X-Application: announcement\r\n"); append_hf("X-Announcement-Playback: wrong-number\r\n"); route(TO_ANNOUNCEMENT); exit; } # next DST - only for 500 or local timeout if (t_check_status("500") or (t_branch_timeout() and !t_branch_replied())) { xlog("selecting next destination"); if (ds_next_dst()) { t_on_failure("RTF_DISPATCH"); route(RELAY); exit; } } } # Routing to announcement server route[TO_ANNOUNCEMENT] { if (!is_method("INVITE")) { return; } rewritehostport('ANNOUNCEMENT_SERVER:5060'); route(RELAY); exit; }

2 3

Problem with selection Transport Protocol - MultiHomed Problem
by YAS0 CANER 17 Dec '18

17 Dec '18

Hello , i have trouble about selection transport protocol. i have tried so many thing but couldnt find TM selected which IPv? and protocol type (TCP or UDP) For example; i have 2 interface ipv6 and ipv4. i will route my message (INVITE-Register etc.) another node that use TCP and IPV6 , domain name is test1.test. TM module or some module resolve this domain to IPV6:UDP but i want to sent it over IPV6:TCP socket. so i cannot know which protocol is resolved and cannot route the right socket. $du variable show only sip:ali@test1.test Conclusion : There isn't any pseudo value about which destination of IP version will use. Thanks Flow: UAC (IPv4:UDP) ----------> Kamailio (MultiHomed) ----> (TCP:IPv6)Kamailio ---- Kamailo (multiHomed ) cfg ------ auto_bind_ipv6=1 dns_try_ipv6=yes dns_retr_time=1 dns_retr_no=1 dns_cache_flags=4 mhomed=1 fork=yes tcp_source_ipv6 = [fd61:c23c:b3b6::5] listen=tcp:[fd61:c23c:b3b2::5]:5060 listen=udp:[fd61:c23c:b3b2::5]:5060 listen=udp:192.168.1.107:5060 listen=tcp:192.168.1.107:5060 route []{ if($dP=="TCP"){ xlog("L_INFO","[route] [TCP] 1\n"); if (!t_relay_to_tcp()) { xlog("L_ERR", "Error t_relay [route] \n"); t_reply("500","Server - ERROR "); exit; } } else if($dP=="TCP"){ xlog("L_INFO","[route] [TCP] 2\n"); if (!t_relay_to_tcp()) { xlog("L_ERR", "Error t_relay [route] \n"); t_reply("500","Server - ERROR "); exit; } }else if($dP=="UDP"){ xlog("L_INFO","[route] [UDP] 1\n"); if (!t_relay_to_udp()) { xlog("L_ERR", "Error t_relay [route] \n"); t_reply("500","Server - ERROR "); exit; } }else{ xlog("L_INFO","[route] [??] 1\n"); if (!t_relay()) { xlog("L_ERR", "Error t_relay [route] \n"); t_reply("500","Server - ERROR "); exit; } } }

2 5

Re: [SR-Users] sr-users Digest, Vol 163, Issue 15
by Toufic Mobarak 17 Dec '18

17 Dec '18

Tnhxtx Regards, Toufic Mobarak > On Dec 15, 2018, at 6:00 AM, sr-users-request(a)lists.kamailio.org wrote: > > Send sr-users mailing list submissions to > sr-users(a)lists.kamailio.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > or, via email, send a message with subject or body 'help' to > sr-users-request(a)lists.kamailio.org > > You can reach the person managing the list at > sr-users-owner(a)lists.kamailio.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sr-users digest..." > > > Today's Topics: > > 1. Re: Routing of Audio and Video Stream. (Daniel-Constantin Mierla) > 2. Problem with selection Transport Protocol - MultiHomed > Problem (YAS0 CANER) > 3. Re: Problem with selection Transport Protocol - MultiHomed > Problem (YAS0 CANER) > 4. Re: Routing of Audio and Video Stream. (Sergiu Pojoga) > 5. Re: Problem with selection Transport Protocol - MultiHomed > Problem (Daniel-Constantin Mierla) > 6. Issue on kamailio 4.1.9 of database reconnection (Emmanuel BUU) > 7. Re: Routing of Audio and Video Stream. (Abhijit Dutta) > 8. Re: Routing of Audio and Video Stream. (Abhijit Dutta) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 Dec 2018 12:54:44 +0100 > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > To: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.kamailio.org>, Abhijit Dutta <duttaa(a)hotmail.com> > Subject: Re: [SR-Users] Routing of Audio and Video Stream. > Message-ID: <26c51f12-5242-4794-5124-f37bc523c7ae(a)gmail.com> > Content-Type: text/plain; charset="windows-1252" > > Hello, > > > I guess you still need to send the INVITE to Asterisk, right? > > > Cheers, > Daniel > > >> On 14.12.18 11:15, Abhijit Dutta wrote: >> Hi All, >> >> Is it possible to redirect only the audio stream towards Asterisk from >> Kamailio (Proxy) via RTPEngine and not to send the video stream to >> Asterisk. I am yet to get the complete reason why my client wants this >> to happen though. >> >> Thanks >> Abhijit >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> sr-users(a)lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com > Kamailio Advanced Training -- www.asipto.com > >

2 1

Automating installation
by John Tuxies 14 Dec '18

14 Dec '18

Hi all. I am new to this and i would like some help please. I am looking to deploy Kamailio and Asterisk in my systems and i would like to automate the process. I have found a bash script but it it outdated from here: https://github.com/gurumelo/asteriskkamailio i did some changes and modifications to adapt it to newer version of software, but it fails to start Kamailio and continue to Asterisk. I would appreciate if someone could help me with this script and make it work. The systems i am planning to execute it is in Debian 9 and Ubuntu 18.04 server, both 64bit. Sincerely yous, John

8 21

FreeBSD Kamailio pkg
by Sergiu Pojoga 14 Dec '18

14 Dec '18

Did anyone notice that when installing Kamailio from FreeBSD package, by default, it accepts registration with whatever account credentials? Not sure if it's like that with other OS packages (usually I install it from source), but this behavior kind of doesn't go with the popular saying that Kamailio by default "does nothing", lol. Regards, --Sergiu

3 4

Kamailio ERROR: _reply_light(): can't generate xxx reply when a final yyy was sent out
by Olli Attila 13 Dec '18

13 Dec '18

Hello, I'm getting these error messages on kamailio log from time to time: Dec 11 19:18:30 /usr/sbin/kamailio[23913]: ERROR: tm [t_reply.c:482]: _reply_light(): can't generate 487 reply when a final 200 was sent out Dec 8 04:44:56 /usr/sbin/kamailio[14960]: ERROR: tm [t_reply.c:482]: _reply_light(): can't generate 487 reply when a final 486 was sent out Dec 5 07:46:04 /usr/sbin/kamailio[14961]: ERROR: tm [t_reply.c:482]: _reply_light(): can't generate 487 reply when a final 480 was sent out Kamailio is configured to act as a proxy between SBC and a softswitch. According to the signaling we can see that these errors occure when the SBC sends CANCEL message towards Kamailio when at the same time final reply is received from the Softswitch side. The call seems to be teared down nicely and finally Kamailio replies to SBC by sending "200 ok, no more pending brances". I guess Kamailio treats this situation as an error because the sip processing engine has sent the final reply out and at the same time SBC sends the CANCEL to Kamailio. Is there any way we could handle this situation better on Kamailio end? The three example ERROR messages are from cases where B subscriber has answered the call, the B has been busy and the last one is from a case where B subscriber has been temporarily unavailable. Cheers, Olli

2 4

is_e164 logic to detect valid number
by Patrick Wakano 11 Dec '18

11 Dec '18

Hello list, Hope you are all doing fine! I am using the is_e164() function to validate the number we receive, and I come to see that the number +555 was accepted.... After some googling it looks like(it is not very clear though) that 7 digits are the minimum we could have for e164 numbers but after checking the source code, I saw it accepts anything starting with + and having between 2 and 16 numbers. So is it really valid to have a number with just 2 digits? What is the case? Thank you, Kind regards, Patrick Wakano

5 7

Performance tests of native vs. kemi scripting for SIP routing
by Daniel-Constantin Mierla 11 Dec '18

11 Dec '18

Hello, during the preparations of Kamailio v5.2.0 and the days after, I got the time to run some tests in order to see the differences of running similar SIP routing logic when using native configuration file scripting versus KEMI languages. So far I did it for Lua and Python (v2), hopefully I will find time to run also for the rest of supported scripting languages: Python (v3), JavaScript, Ruby, Squrrel and Lua with LuaJIT. The pleasant surprise was to see that this time, the results of using Python were similar to native scripting and Lua. When I did some basic tests during development of KEMI, using Python seemed slower. More details about how tests were performed, the config files/scripts, used tools and results were published in a wiki page: - https://www.kamailio.org/wiki/kemi/performance-tests/5.2.x A news article with further details is on kamailio website: - https://www.kamailio.org/w/2018/12/performance-tests-for-kemi-scripting-lan… Should anyhow of you have some time to run the tests in own environment and share the results (on sr-users mailing list), it would be appreciated and would help to validate the tests and discover if I forgot something in any of the configs. Note that the goal of the tests is not measuring the capacity of Kamailio in your environment, but see the differences between using different scripting languages in the same environment (so you can do the tests on raspberry pi, if you like). I would also be interested in knowing if you are using Kamailio with KEMI or you are planning to, if yes, which scripting language. If already doing it, is already in production? These are useful to plan where to allocate developer resources in the future... And to start, I am running Kamailio with Lua (4 instances) and Python (1) scripting in production deployments, with very good results so far. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training -- www.asipto.com

2 2

core at kamailio 5.1.6
by David Escartín 11 Dec '18

11 Dec '18

hello all we are seeing in a new kamailio instance some crashes. We are not sure the root cause, here you have the last core generated https://pastebin.com/xMRrug2X COuld you please take a look to see if there might be any issue with the last message that caused the core (to me seems normal) or there might be some issues related to other system libraries, etc? thanks a lot and regards david

3 7

DTLS HA redis-pacemaker-corosync
by Жан Базаров 10 Dec '18

10 Dec '18

Hello! Are there any ways to implement using DTLS in redis HA scenario? When I reboot the active RTPEngine server the system correctly fails over to the other server and, after only a small pause (~1s), incoming audio continues to arrive. However, approximately 15 seconds after this I hear nothing but silence. Thanks.

2 1

Kamailio World 2019 - Call for Presentations
by Daniel-Constantin Mierla 10 Dec '18

10 Dec '18

Hello, I would like to announce that Call for Presentations at Kamailio World 2019 is now open. You can submit your proposal or see more details at: - https://www.kamailioworld.com/k07/call-for-speakers/ The 7th edition of the event takes place again in Berlin, Germany, during May 6-8, 2019. Expect over 150 participants, developers and community members as well as representatives from other popular open source VoIP projects such as Asterisk or FreeSwitch. Looking forward to meeting many of you there! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training -- www.asipto.com

1 0

SIP SIMPLE TO XMPP AND VICE VERSA
by sagar malam 08 Dec '18

08 Dec '18

Hello, We have a system which using FreeSWITCH for calls and Ejabberd( XMPP) for chat.Now we want to support SIP SIMPLE as well.But we are not going to move old users to SIP SIMPLE but only new users will use SIP SIMPLE.This leads to requirement of having SIP-XMPP gateway for which are are considering Kamailio server. I have gone through documentation about Kamailio XMPP module, it is clear that Kamailio can convert SIP MESSAGE to XMPP so SIP to XMPP will work but what about XMPP to SIP MESSAGE ? Does that work as well ? Thanks in advance. -- Thanks, Sagar

2 2

Dialplan Module limits
by Enrico Bandiera 07 Dec '18

07 Dec '18

Hi guys, does anyone know which are the limits of the diaplan module? After how many entries I will encounter serious performance issues? Thanks, Enrico.

2 1

question about replace_body_all
by Wilkins, Steve 07 Dec '18

07 Dec '18

Hello, I am attempting to change the Message Body of an SIP message using replace_body_all; I want to replace all attributes that start with rtcp. Here is my code => replace_body_all("rtcp:{1}[0-9]{5,}", newstring), and I call msg_apply_changes() after this call. Note that I verified that the regex is working using search. The problem is that nothing gets changed. However, what I do get is a new string at the bottom of the Message Body with my newstring concatenated three times, which happens to be the number of times that rtcp occurs in the Message Body. Note, I am doing this so that I can add the IP address to the rtcp attribute because this is required by a Provider. Any ideas? Thank you, -Steve

3 2

Dialog getting disconnected as soon as call is ended
by Subham Singhal 07 Dec '18

07 Dec '18

Hello, I am new to kamailio. I have been trying to integrate kamailio with asterisk. I am able to send INVITE and get RTP packets as well, but I am unable to receive BYE from asterisk. Call is getting terminated through following websocket error. "WebSocket connection to 'wss://172.16.16.169:5061/' failed: One or more reserved bits are on: reserved1 = 1, reserved2 = 0, reserved3 = 0." -- Thanks and Regards Subham Singhal

2 1

Auth_xkeys module - freeing already freed pointer
by José Seabra 06 Dec '18

06 Dec '18

Hello there, I'm constantly getting the following message when i'm using module auth_xkeys. CRITICAL: <core> [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing already freed pointer (0x7f6310987400), called from core: core/data_lump.c: free_lump(466), first free core: core/data_lump.c: free_lump(466) - ignoring Apparently kamailio only throw this message but i would like to know if its a normal protection from kamailio or it should be fixed? Thank you for the support Regards -- José Seabra

3 5

Assistance with re.subst & newline
by Mark Hall 06 Dec '18

06 Dec '18

Hi, I am using rtpengine to proxy audio to/from media servers. The outbound calls are being rejected by a couple of my carriers (although accepted by others), and the closest that I have been able to find for the reason is the inclusion of "a=rtcp:xxxxx" in the SDP generated by rtpengine. To test further, I am trying to remove this line. Rtpengine itself doesn't have any options to remove it, so I am left with manipulating the generated SDP in Kamailio. A sample of generated SDP is: a=maxptime:150 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-16 a=sendrecv a=rtcp:30939 s=My Media Server I am using rtpengine_manage("RTP/AVP ICE=remove"); to generate the SDP to a variable ($avp(sdp)) Now, I am trying to just remove the whole a=rtcp line with re.subst $avp(sdp)=$(avp(sdp){re.subst,|a=rtcp:[0-9]*\R||s}); *** Tried / as delimiter also, but | looks cleaner *** This should match the line and any CR/LF characters - BUT in results, nothing is changed (various online Regex testers show this match to be correct - I tried \r\n also). If I do the same but without the \R, then the line is removed but not the CR/LF, leaving a gap in the SDP - which is invalid. $avp(sdp)=$(avp(sdp){re.subst,|a=rtcp:[0-9]*||s}); Gives: a=maxptime:150 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-16 a=sendrecv s=My Media Server Can anyone see where I am going wrong, or suggest an alternative? Kind Regards, Mark Hall

3 3

New features: dialog - list dialogs via rpc using matching expressions
by Daniel-Constantin Mierla 06 Dec '18

06 Dec '18

Hello, being discussed and requested couple of times via lists, irc channel and discussions at events world wide, I just want to send a short note to announce that yesterday I pushed a new rpc command to dialog module that returns dialog records that match on conditions applied to request uri, from uri, to uri or callid fields. The filtering can be done with string comparison, regular expression or starts-with (prefix) matching. See more details at: - https://www.kamailio.org/docs/modules/devel/modules/dialog.html#dlg.r.list_… It should enable listing dialogs only for specific users, caller or callee, without dumping all dialogs. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

1 0

set_advertised_address
by Kjeld Flarup 06 Dec '18

06 Dec '18

Hello I have a PBX behind NAT. Thus I advertise the public IP, and forwards the port to my PBX. listen=LOCALIP:5070 advertise EXTERNALIP:5070 Now clients can connect to the PBX from the Internet. And also inside the LAN, because I have enabled NAT loopback. However some customers sysadmins complains that NAT loopback is a security risk. I have not been able to find any exploits of this, but the sales and support people asks if it is possible to remove this NAT loopback requirement. I could look at $rd and if it is local, then I could advertise LOCALIP. I found set_advertised_address("LOCALIP"); set_advertised_address however only seems to modify the latest Via header, not the Record-route, and audio neither works. Could I do something to make this work, or is it a dead end? -- -------------------- Med Liberalistiske Hilsner ---------------------- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

4 11

Dispatcher clear dst_avp
by Grant Bagdasarian 05 Dec '18

05 Dec '18

Hello, I'm trying to use multiple destination sets which may include the same destination. For instance: SET ID: 1 sip:10.0.0.1:5060 sip:10.0.0.2:5060 SET ID: 2 sip:10.0.0.1:5060 Whenever a new SIP INVITE is sent to the Kamailio instance it will use SET ID 1. If then for some reason this call attempt fails, failure_route will trigger and SET ID 2 will be used. At first glance this might not make any sense, but there is some business logic behind this, but it's not relevant for this case. For some reason, the dst_avp variable still contains the destinations of SET ID 1 in failure_route. Is there a built-in way to reset this variable for every call to ds_select_domain(), such that only the destinations of passed SET ID will be loaded into the avp? I tried setting the avp to $null before calling ds_select_domain, but that had some undesirable effects. The reason I'm asking this is the destinations the call is being sent to are Freeswitch instances, which will return a 482 Request Merged when the same INVITE is sent to the same Freeswitch within 4 seconds (default T4 timer). I'm trying to match the previously selected destination in failure_route with the next destination and skip if they're the same, or stop processing when they are the same and no more destinations are available. I know I can mess with the T4 timer in Freeswitch and perhaps even sleep in failure route to deal with the 482 failure, but I rather fix this in a normal way. Regards, Grant Bagdasarian Senior Developer

2 2

xlog issue
by Soltanici Ilie 04 Dec '18

04 Dec '18

Hello, I have a strange situation by using xlog module. I don't know for what reason I'm not receiving all logs generated by kamailio. This is the configuration which I'm using in kamailio.cfg: log_facility=LOG_LOCAL0 log_name="kamailio" log_prefix="{$rm ($mt) | Seq=$cs | Source IP=$si ($proto) | Call ID=$ci} " # ----- xlog ----- modparam("xlog", "buf_size", 8192) modparam("xlog", "long_format", 0) modparam("xlog", "force_color", 1) modparam("xlog", "log_colors", "L_ERR=cr;L_WARN=px,L_INFO=px") This is rsyslog configuration file: local0.* /var/log/kamailio/kamailio.log Kamailio is running under kamailio user, permission for the log file are as shown below: -rwxrwxr-x 1 kamailio kamailio 252885132 Dec 2 14:51 /var/log/kamailio/kamailio.log In request_route block this is the first line: xlog("L_INFO","[START ROUTING]-(Source IP=$si:$sp/Destination IP=$Ri:$Rp)\n"); The problem is that not every request is logged in the log-file. For example, some "INVITES" requests I can find in the log file, but some of them - I cannot, even that in sngrep I see the request and the call is successfully processed by kamailio. Also, for some requests i can see only partial data, not full call-flow as it supposed to be (for ex. i see only BYE requests, or ACK response instead of full call flow). Does someone have the same issue? If you don't - how are you dealing with kamailio log files? I'm thinking to send them to the central ELK stack, but if I have such problems by saving them locally - I don't see any reason to send them elsewhere. I may think that the problem could be in rsyslog itself, but how can I troubleshoot that? The traffic on the server is not very high - 30-50 concurrent calls. As a storage i'm using an SSD disk and xfs filesystem. Load on the disk - according to iostat/iotop - is minimum. OS: CentOS Linux 7 (Core), Kamailio: 5.2.0 (x86_64/linux) 535e13 Thank You.

3 9

presence/mwi issue
by Andreas Granig 04 Dec '18

04 Dec '18

Hi, Currently playing with presence_mwi in kamailio 5.1, and it appears the issue reported by Juha two years ago at https://lists.kamailio.org//pipermail/sr-dev/2016-September/036609.html seems to have appeared again somewhere along the way. I’m sending a PUBLISH with message-summary event type, however I’m getting this error: ERROR: presence [presentity.c:283]: check_if_dialog(): failed to parse xml document As said in the old thread, it’s not an XML document, so it shouldn’t try to treat it as such. Any ideas? Best, Andreas

2 8

Dispatcher with a naptr address as destination
by José Seabra 04 Dec '18

04 Dec '18

Hello all, I'm trying to use a naptr address as a dispatcher destination and i'm facing some issues here. When i configure a naptr address in dispatcher table, like: *1:1:sip\:proxy-registrar-ci1.fuze.domain:0:0:'':''* I see kamailio making a dns query of type A, but since that this name doesn't have any A record configured in dns, kamailio didn't get any positive reply from it. Should't kamailio make dns query by this order? 1. NAPTR 2. SRV 3. A I noticed also that if the name configured in dispatcher table is resolved successfully with A record from dns, then kamailio tries to make a query to NAPTR and then SRV services for the exactly same name used for query previously done(type A), but only if it gets a positive answer from dns to the A type query. I'm using kamailio version 5.1.0 with the following dns parameters configured: ####### DNS Parameters ######### dns = no rev_dns = no dns_try_ipv6 = no dns_retr_time = 1 dns_retr_no = 1 dns_cache_del_nonexp = no dns_cache_flags = 1 dns_cache_gc_interval = 120 dns_cache_init = 1 dns_cache_mem = 1000 dns_cache_negative_ttl = 60 dns_try_naptr = yes use_dns_cache = on use_dns_failover = on dns_srv_lb = yes Is there something wrongly configured here that can make kamailio behaves like that? Thank you. Regards -- Cumprimentos José Seabra

4 8

Issue with ACK's
by Dan Quinney 30 Nov '18

30 Nov '18

Hi all, I’m having some issues with ACK’s. Specifically, when an ACK reaches Kamailio from either Asterisk or an endpoint, Kamailio is adding a second Via header - which isn’t valid as per RFC 3261 (17.1.1.3); “The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request." Endpoints are registered with Kamailio but INVITES are routed via Asterisk for dial plan and media reasons. I’m running fairly bog-standard Kamailio and Asterisk installs. I’ve attached a sample PCAP for if anyone has any suggestions. Thanks. Dan

2 2

Issue with ACK's
by Dan Quinney 30 Nov '18

30 Nov '18

Hi all, I’m having some issues with ACK’s. Specifically, when an ACK reaches Kamailio from either Asterisk or an endpoint, Kamailio is adding a second Via header - which isn’t valid as per RFC 3261 (17.1.1.3); “The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request." Endpoints are registered with Kamailio but INVITES are routed via Asterisk for dial plan and media reasons. I’m running fairly bog-standard Kamailio and Asterisk installs. I’ve attached a sample PCAP for if anyone has any suggestions. Thanks. Dan

1 0

Kamailio v5.2.0 Released - new major version is out
by Daniel-Constantin Mierla 30 Nov '18

30 Nov '18

Kamailio v5.2.0 is out – it comes with 6 new modules and a consistent group of improvements touching more than 100 existing modules. You can read detailed release notes at: * https://www.kamailio.org/w/kamailio-v5-2-0-release-notes/ Many thanks to all developers and community members that made possible this release. v5.2.0 brings more flexibility and optimizations for KEMI interpreters (including two new interpreters for Python3 and Ruby), major enhancements to load balancer and tls implementations, new variables and lots of other new features. Enjoy Kamailio v5.2.0! Thank you for flying Kamailio! Daniel -- Daniel-Constantin Mierla http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference 2019 - http://www.kamailioworld.com

2 2

Response VIA Header
by Soltanici Ilie 29 Nov '18

29 Nov '18

Hi, We have a Kamailio Instance running on Public IP Address, one of our ISP cannot send ACK back to us because we are sending 100 Trying - without "received" parameter. Is there any way in Kamailio to force a "received" parameter in the via header for 100 Trying Message? SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP X.X.X.X:5060;branch=z9hG4bK8tgchsfjaKJdf.1;rport=5060 Thank you.

2 1

Forward() not handles Route headers
by Yuriy Gorlichenko 29 Nov '18

29 Nov '18

We are building some stateless solution and found that in case of using forward() kamailio sends traffic only via URI or $du variable. It never removes itself from route headers. Is this is the truth? Or I need to add some other module to handle it? (rr already added)

1 1

KAMAILIO 4.2 - RTPPROXY config confirmation - error message from systemctl status kamailio.service -l (ERROR: <script>: NATMANAGE coee)
by yboujraf＠by-research.be 28 Nov '18

28 Nov '18

Dear All, I am still using Kamailio 4.2 with Debian Jessie without any issues. RTPPROXY - CONFIG > # Defaults for rtpproxy > # The control socket. > #CONTROL_SOCK="unix:/var/run/rtpproxy/rtpproxy.sock" > # To listen on an UDP socket, uncomment this line: > CONTROL_SOCK=udp:127.0.0.1:7722 > # Additional options that are passed to the daemon. > > # log in /var/log/kamailio.log > EXTRA_OPTS="-l ip_public/192.168.40.101 -m 11000 -M 12000 -d DBUG:LOG_LOCAL0" WHEN I MAKE AN INVITE FROM 801 TO 803, I HAVE THIS ERROR MESSAGE : KAMAILIO SERVICE (ERROR: <SCRIPT>: NATMANAGE COEE) root@sipsecure:~# systemctl status kamailio.service -l ● kamailio.service - LSB: Start the Kamailio SIP proxy server Loaded: loaded (/etc/init.d/kamailio) Active: active (running) since Tue 2018-11-20 22:34:31 CET; 40s ago Process: 1820 ExecStop=/etc/init.d/kamailio stop (code=exited, status=0/SUCCESS) Process: 1830 ExecStart=/etc/init.d/kamailio start (code=exited, status=0/SUCCESS) CGroup: /system.slice/kamailio.service ├─1846 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1848 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1849 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1850 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1851 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1852 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1853 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1854 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1855 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1856 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1858 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1860 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1863 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1865 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1867 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1869 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1871 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio ├─1873 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio └─1875 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg -P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1853]: ERROR: <script>: NATMANAGE coee Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1854]: ERROR: <script>: NATMANAGE M=INVITE OU=<null> RURI=<null> RD=<null> F=sip:801@192.168.40.101;transport=UDP T=sip:803@192.168.40.101;transport=UDP NH=<null> IP=192.168.0.207 ID=fjpUwRGm0u--3RvvB4fZ7Q.. Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1854]: ERROR: <script>: NATMANAGE coee Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1855]: ERROR: <script>: NATMANAGE M=INVITE OU=<null> RURI=<null> RD=<null> F=sip:801@192.168.40.101;transport=UDP T=sip:803@192.168.40.101;transport=UDP NH=<null> IP=192.168.0.207 ID=fjpUwRGm0u--3RvvB4fZ7Q.. Nov 20 22:35:00 sipsecure /usr/sbin/kamailio[1855]: ERROR: <script>: NATMANAGE coee Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1852]: ERROR: <script>: NATMANAGE M=INVITE OU=<null> RURI=<null> RD=<null> F=sip:801@192.168.40.101;transport=UDP T=sip:803@192.168.40.101;transport=UDP NH=<null> IP=192.168.0.207 ID=fjpUwRGm0u--3RvvB4fZ7Q.. Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1852]: ERROR: <script>: NATMANAGE coee Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1852]: NOTICE: acc [acc.c:317]: acc_log_request(): ACC: transaction answered: timestamp=1542749703;method=INVITE;from_tag=4d488551;to_tag=2006d156;call_id=fjpUwRGm0u--3RvvB4fZ7Q..;code=200;reason=OK;src_user=801;src_domain=192.168.40.101;src_ip=192.168.0.229;dst_ouser=803;dst_user=803;dst_domain=192.168.0.207;user_agent=Z 5.2.19 rv2.8.99 Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1853]: ERROR: <script>: NATMANAGE M=ACK OU=sip:803@192.168.0.207:5060;alias=192.168.0.207:5060~1 RURI=sip:803@192.168.0.207:5060 RD=192.168.0.207 F=sip:801@192.168.40.101;transport=UDP T=sip:803@192.168.40.101;transport=UDP NH=192.168.0.207 IP=192.168.0.229 ID=fjpUwRGm0u--3RvvB4fZ7Q.. Nov 20 22:35:03 sipsecure /usr/sbin/kamailio[1853]: ERROR: <script>: NATMANAGE coee Don't understand why the error??? RTPPROXY SERVICE : (RTPPROXY IS DOING HIS JOB PERFECTLY AND GET AUDIO ON BOTH DIRECTION) root@sipsecure:~# systemctl status rtpproxy.service -l ● rtpproxy.service - LSB: RTP Proxy Loaded: loaded (/etc/init.d/rtpproxy) Active: active (running) since Tue 2018-11-20 22:13:58 CET; 22min ago Process: 443 ExecStart=/etc/init.d/rtpproxy start (code=exited, status=0/SUCCESS) CGroup: /system.slice/rtpproxy.service └─1137 /usr/bin/rtpproxy -s udp:127.0.0.1 7722 -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 212.76.231.102 192.168.40.101 -m 11000 -M 12000 -d DBUG LOG_LOCAL0 Nov 20 22:34:31 sipsecure rtpproxy[1137]: DBUG:doreply: sending reply "1875_11 1 " Nov 20 22:35:00 sipsecure rtpproxy[1137]: DBUG:handle_command: received command "1853_8 USEEc106,9,3,111,0,8,97,110,112,98,101,100,99,102 fjpUwRGm0u--3RvvB4fZ7Q.. 192.168.0.229 11000 4d488551;1" Nov 20 22:35:00 sipsecure rtpproxy[1137]: INFO:handle_command: new session fjpUwRGm0u--3RvvB4fZ7Q.., tag 4d488551;1 requested, type strong Nov 20 22:35:00 sipsecure rtpproxy[1137]: INFO:handle_command: new session on a port 11496 created, tag 4d488551;1 Nov 20 22:35:00 sipsecure rtpproxy[1137]: INFO:handle_command: pre-filling caller's address with 192.168.0.229:11000 Nov 20 22:35:00 sipsecure rtpproxy[1137]: DBUG:doreply: sending reply "1853_8 11496 192.168.40.101 " Nov 20 22:35:03 sipsecure rtpproxy[1137]: DBUG:handle_command: received command "1852_8 LSEEc106,9,3,111,0,8,97,110,112,102,98,101,100,99 fjpUwRGm0u--3RvvB4fZ7Q.. 192.168.0.207 11112 4d488551;1 2006d156;1" Nov 20 22:35:03 sipsecure rtpproxy[1137]: INFO:handle_command: lookup on ports 11496/11402, session timer restarted Nov 20 22:35:03 sipsecure rtpproxy[1137]: INFO:handle_command: pre-filling callee's address with 192.168.0.207:11112 Nov 20 22:35:03 sipsecure rtpproxy[1137]: DBUG:doreply: sending reply "1852_8 11402 192.168.40.101 " ??? Question : for rtpproxy config, do I need to add the natted ip address (NAT 1:1) or the real public address (where ip phone needs to assign as domain)? I am confused. Thanks a lot in advance Best Regards, Youssef

3 6

Issue sending SIP OPTIONS request to multiple contacts
by Dan Quinney 28 Nov '18

28 Nov '18

Hi, When using Kamailio v5.2.0-rc2 (x86_64/linux) 9e729b and setting the below nathelper module parameters it appears only the first contact is sent a SIP OPTIONS request. modparam("nathelper", "natping_interval", 15) modparam("nathelper", "ping_nated_only", 0) modparam("nathelper", "sipping_bflag", FLB_NATSIPPING) modparam("nathelper", "sipping_from", "sip:ping@mydomain <sip:ping@mydomain>.com") modparam("nathelper", "keepalive_timeout", 90) Reading the release notes for v5.2 what I’m doing *should* be possible, but as the functionality has been recently added I’m assuming that it might be a bug. Any assistance on this would be great. Thanks, Dan

2 1

Releasing Kamailio v5.2.0
by Daniel-Constantin Mierla 28 Nov '18

28 Nov '18

Hello, I am consider to release v5.2.0 (the first stable version out of branch 5.2) next week, likely on Wednesday, Nov 28, 2018. It still allows a bit more than a week of testing as well as well time to prepare the online resources for it (documentation, wiki pages, upgrade guidelines, etc...). If there is any issue you are of and not yet reported to github bug tracker, do it as soon as possible to give it a chance to be fixed in time for the next major release. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

1 2

Error opening Kamailio's FIFO
by Markus 28 Nov '18

28 Nov '18

Hi list, when I run "/usr/sbin/kamctl address reload" I get: ERROR: Error opening Kamailio's FIFO /tmp/kamailio_fifo ERROR: Make sure you have the line 'modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")' in your config ERROR: and also have loaded the mi_fifo module. In /etc/kamailio/kamailio.cfg I have: loadmodule "mi_fifo.so" # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") But there's no fifo in /tmp. What am I doing wrong? kamailio-4.4.4-1.1.x86_64 on CentOS Linux release 7.2.1511 (Core). Thank you! Markus

3 8

[CFP] FOSDEM 2019, RTC devroom, speakers, volunteers neeeded
by FOSDEM RTC Team 28 Nov '18

28 Nov '18

FOSDEM is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2019 takes place 2-3 February 2019 in Brussels, Belgium. https://fosdem.org This email contains information about: - Real-Time Communications dev-room and lounge, - speaking opportunities, - volunteering in the dev-room and lounge, - social events (the legendary FOSDEM Beer Night and Saturday night dinners provide endless networking opportunities), - the Planet aggregation sites for RTC blogs Call for participation - Real Time Communications (RTC) ======================================================= The Real-Time dev-room and Real-Time lounge is about all things involving real-time communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP, codecs, peer-to-peer, privacy and encryption. The dev-room is a successor to the previous XMPP and telephony dev-rooms. We are looking for speakers for the dev-room and volunteers and participants for the tables in the Real-Time lounge. The dev-room is only on Sunday, 3rd of February 2019. The lounge will be present for both days. To discuss the dev-room and lounge, please join the Free RTC mailing list: http://lists.freertc.org/mailman/listinfo/discuss To be kept aware of major developments in Free RTC, without being on the discussion list, please join the Free-RTC Announce list: http://lists.freertc.org/mailman/listinfo/announce Speaking opportunities ---------------------- Note: if you used FOSDEM Pentabarf before, please use the same account/username Real-Time Communications dev-room: deadline 23:59 UTC on 2nd of December. Please use the Pentabarf system to submit a talk proposal for the dev-room. On the "General" tab, please look for the "Track" option and choose "Real Time Communications devroom". https://penta.fosdem.org/submission/FOSDEM19/ Other dev-rooms and lightning talks: some speakers may find their topic is in the scope of more than one dev-room. It is encouraged to apply to more than one dev-room and also consider proposing a lightning talk, but please be kind enough to tell us if you do this by filling out the notes in the form. You can find the full list of dev-rooms at https://www.fosdem.org/2019/schedule/tracks/ and apply for a lightning talk at https://fosdem.org/submit Main track: the deadline for main track presentations is 23:59 UTC 3rd of November. Leading developers in the Real-Time Communications field are encouraged to consider submitting a presentation to the main track at https://fosdem.org/submit First-time speaking? -------------------- FOSDEM dev-rooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the dev-room administrators personally if you would like to ask any questions about it. Submission guidelines --------------------- The Pentabarf system will ask for many of the essential details. Please remember to re-use your account from previous years if you have one. In the "Submission notes", please tell us about: - the purpose of your talk - any other talk applications (dev-rooms, lightning talks, main track) - availability constraints and special needs You can use HTML and links in your bio, abstract and description. If you maintain a blog, please consider providing us with the URL of a feed with posts tagged for your RTC-related work. We will be looking for relevance to the conference and dev-room themes, presentations aimed at developers of free and open source software about RTC-related topics. Please feel free to suggest a duration between 20 minutes and 55 minutes but note that the final decision on talk durations will be made by the dev-room administrators based on the number of received proposals. As the two previous dev-rooms have been combined into one, we may decide to give shorter slots than in previous years so that more speakers can participate. Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used. Volunteers needed ================= To make the dev-room and lounge run successfully, we are looking for volunteers: - FOSDEM provides video recording equipment and live streaming, volunteers are needed to assist in this - organizing one or more restaurant bookings (dependending upon number of participants) for the evening of Saturday, 2nd of February - participation in the Real-Time lounge - helping attract sponsorship funds for the dev-room to pay for the Saturday night dinner and any other expenses - circulating this Call for Participation to other mailing lists Social events and dinners ========================= The traditional FOSDEM beer night occurs on Friday, 1st of February. On Saturday night, there are usually dinners associated with each of the dev-rooms. Most restaurants in Brussels are not so large so these dinners have space constraints and reservations are essential. Please subscribe to the Free-RTC mailing list for further details about the Saturday night dinner options and how you can register for a seat: http://lists.freertc.org/mailman/listinfo/discuss Spread the word and discuss =========================== If you know of any mailing lists where this CfP would be relevant, please forward this email. If this dev-room excites you, please blog or microblog about it, especially if you are submitting a talk. If you regularly blog about RTC topics, please send details about your blog to the planet site administrators: All projects http://planet.freertc.org planet(a)freertc.org XMPP http://planet.jabber.org ralphm(a)ik.nu SIP http://planet.sip5060.net planet(a)sip5060.net (Español) http://planet.sip5060.net/es/ planet(a)sip5060.net Please also link to the Planet sites from your own blog or web site as this helps everybody in the free real-time communications community. Contact ======= For any private queries, contact us directly using the address fosdem-rtc-admin(a)freertc.org and for any other queries please ask on the Free-RTC mailing list: http://lists.freertc.org/mailman/listinfo/discuss The dev-room administration team: Saúl Ibarra Corretgé <s(a)saghul.net> Ralph Meijer <ralphm(a)ik.nu> Daniel-Constantin Mierla <miconda(a)gmail.com> Daniel Pocock <daniel(a)pocock.pro> Guus der Kinderen <guus.der.kinderen(a)gmail.com>

2 1

Dialiog and dispatcher
by David Villasmil 27 Nov '18

27 Nov '18

Hello guys, I'm testing the dispatcher with the dialog module. After making several test calls, which are properly routed, the number of dialogs stay there for a while, preventing new calls from going to those destinations: "SET": { "ID": 101, "TARGETS": [{ "DEST": { "URI": "sip:1.2.3.4:5080", "FLAGS": "AP", "PRIORITY": 0, "ATTRS": { "BODY": "weight=100;maxload=10;duid=bedd39c7-6c73-4477-ae7d-77f8cdc96797", "DUID": "bedd39c7-6c73-4477-ae7d-77f8cdc96797", "MAXLOAD": 10, "WEIGHT": 100, "RWEIGHT": 0, "SOCKET": "" }, "RUNTIME": { "DLGLOAD": 10 } } }] The calls have been down for several seconds, but the "DLGLOAD" parameter doesn't go down, even though /usr/local/kamailio5/sbin/kamctl', 'dialog', 'show Output the correct amount of dialogs. I set the dialog handler just before relaying out: t_on_failure("RTF_DISPATCH"); set_dlg_profile("gateways","$du"); route(RELAY); And the module is supposed to remove them automatically. Am i doing something wrong? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

2 2

dispatcher: Get gateway current calls
by David Villasmil 27 Nov '18

27 Nov '18

Hello guys, is there any way of printing out the selected gw current calls? i.e.: if(ds_select_dst("1", "4")) { xlog("L_ERR", "[DISPATCH] $ci: ds_select_routes was succesful (du: <$du>)\n"); ****** PRINT GWs CALLS ******* } else { xlog("L_ERR", "[DISPATCH] $ci: did NOT find a gateway to use!\n"); send_reply("404", "No destination"); exit; } xlog("L_DBG", "[DISPATCH] $ci: going to <$ru> via <$du>\n"); t_on_failure("RTF_DISPATCH"); route(RELAY); Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

2 1

Re: [SR-Users] "kamdbctl create" failing with MySQL 8
by Jonathan Tyler 26 Nov '18

26 Nov '18

I just had the same thing happen to me. I installed Kamailio via Apt, and I'm using a dedicated MySQL server, with non-root admin credentials. Previously today I installed it using a local MySQL 5.7 database with no issues. Kamailio Host: Kamailio 5.1.2 (Ubuntu 18.04) MySQL Host: MySQL 8.0.13 (Windows Server 2012 R2) It creates the database, then fails at granting permissions. Accounts were created and privileges flushed before executing. > root@kamailio:~# kamdbctl create > INFO: creating database kamailio ... > mysql: [Warning] Using a password on the command line interface can be insecure. > INFO: granting privileges to database kamailio ... > mysql: [Warning] Using a password on the command line interface can be insecure. > ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IDENTIFIED BY '<password>'' at line 1 I turned on query logging on the database host but didn't see any errors there, or in the error log itself. > 2018-11-21T01:58:15.045586Z 8 Connect <user>@kamailio on using SSL/TLS > 2018-11-21T01:58:15.046239Z 8 Query select @@version_comment limit 1 > 2018-11-21T01:58:15.046764Z 8 Query CREATE DATABASE kamailio CHARACTER SET utf8mb4 > 2018-11-21T01:58:15.189109Z 8 Quit > 2018-11-21T01:58:15.208476Z 9 Connect <user>@kamailio on using SSL/TLS > 2018-11-21T01:58:15.209019Z 9 Query select @@version_comment limit 1 > 2018-11-21T01:58:15.210114Z 9 Quit I've tried with the default MySQL 5.7 Client on Ubuntu, and upgrading it to 8.0.13, but got the same result. Unfortunately I don't know how to see the output of the SQL Statement being sent (without installing 5.7), or I'd try to run it manually. - Jonathan

3 5

issue tracking dialogs with db_redis in kamailio 5.2
by David Escartín 26 Nov '18

26 Nov '18

hello all using version 5.2.0-rc0 of kamailio, we are trying to track the dialogs of dialog module using db_redis module with this setup #!define DBURL_DIALOG "redis://127.0.0.1:6390/7" # ----- dialog params ----- modparam("dialog", "db_url", DBURL_DIALOG) modparam("dialog", "enable_stats", 1) modparam("dialog", "hash_size", 16384) modparam("dialog", "dlg_flag", 31) modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "db_mode", 1) modparam("dialog", "timer_procs", 1) modparam("dialog", "db_update_period", 1) # ----- db_redis params ----- modparam("db_redis", "schema_path", "/usr/local/kamailio/share/kamailio/db_redis/kamailio") modparam("db_redis", "keys", "dialog=entry:hash_entry,hash_id,callid") modparam("db_redis", "keys", "dialog_vars=entry:hash_entry,hash_id,dialog_key,dialog_value") and we see it works and if a kamailio instance resets in the middle of a dialog it recovers all the dlg_vars and values because we have the db_skip_load to 0 in dialog module. But we have noticed that the redis is being written with the information of the dlg_var assigned until that moment when we get a provisional response with SDP, and we dom see a set on the redis with the dialog entry and id untill call is connected. Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: INFO: Call-ID 1-1511(a)9.7.8.1: Status 180 Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog' while performing update Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 0 is 'hash_entry' Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 1 is 'hash_id' on the redis (we only see hmset for dialog_vars key) 1542374575.721816 [7 127.0.0.1:56858] "HMSET" "dialog_vars:entry::13725:16494:_uac_funew:sip:1231215423@voda.interconnect.manxtelecom.im" "hash_entry" "13725" "hash_id" "16494" "dialog_key" "_uac_funew" "dialog_value" "sip:1231215423@voda.interconnect.manxtelecom.im" 1542374575.722001 [7 127.0.0.1:56858] "HMSET" "dialog_vars:entry::13725:16494:_uac_fu:sip:anonymous@voda.interconnect.manxtelecom.im" "hash_entry" "13725" "hash_id" "16494" "dialog_key" "_uac_fu" "dialog_value" "sip:anonymous@voda.interconnect.manxtelecom.im" .... Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: INFO: Call-ID 1-1511(a)9.7.8.1: Status 200 Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog_vars' while performing update Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 0 is 'hash_entry' Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 1 is 'hash_id' Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 2 is 'dialog_key' Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog' while performing update Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 0 is 'hash_entry' Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 1 is 'hash_id' Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog' while performing update Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 0 is 'hash_entry' Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 1 is 'hash_id' Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: INFO: Call-ID 1-1511(a)9.7.8.1: ACK received in A-Leg on the redis 1542374585.810520 [7 127.0.0.1:56882] "SCAN" "0" "MATCH" "dialog:entry::*" "COUNT" "1000" 1542374585.810672 [7 127.0.0.1:56882] "EXISTS" "dialog:entry::13725:16494:1-1511@9.7.8.1" 1542374585.810683 [7 127.0.0.1:56882] "HMGET" "dialog:entry::13725:16494:1-1511@9.7.8.1" "hash_entry" "hash_id" 1542374585.810776 [7 127.0.0.1:56882] "HMSET" "dialog:entry::13725:16494:1-1511@9.7.8.1" "state" "4" "timeout" "1542377585" "caller_cseq" "1" "callee_cseq" "0" "caller_contact" "sip:0000123456@9.7.8.1:5084" "callee_contact" "sip:50622959898@9.70.1.52:5060;transport=udp" 1542374585.810899 [7 127.0.0.1:56882] "SCAN" "0" "MATCH" "dialog:entry::*" "COUNT" "1000" 1542374585.810969 [7 127.0.0.1:56882] "EXISTS" "dialog:entry::13725:16494:1-1511@9.7.8.1" 1542374585.810977 [7 127.0.0.1:56882] "HMGET" "dialog:entry::13725:16494:1-1511@9.7.8.1" "hash_entry" "hash_id" 1542374585.811059 [7 127.0.0.1:56882] "HMSET" "dialog:entry::13725:16494:1-1511@9.7.8.1" "state" "4" "timeout" "1542377585" "caller_cseq" "1" "callee_cseq" "0" "caller_contact" "sip:0000123456@9.7.8.1:5084" "callee_contact" "sip:50622959898@9.70.1.52:5060;transport=udp" i don't see a redis set order to update the dialog entry key before the 200OK is received, to create and update state 1, etc. when created with dlg_manage command could you please check if we might be missing something? thanks a lot and regards david

2 3

Kamailio "Presence Server" configuration
by denislav.tsonev＠musala.com 26 Nov '18

26 Nov '18

Hello, I'm trying to configure Kamailio to be "Presence Server". Simple scheme: two phones (one "hard phone" Grandstream GXP1620 and "Soft phone" MicroSIP) and Kamailio server with default configuration. So when "MicroSIP" send SIP SUBSCRIBE to Kamailio, server response with SIP NOTIFY but without XML part. Then when hard phone change his status from "Ready" to "Ringing" and then "On-The-Phone" Kamailio is not sending any SIP NOTIFY messages. Is this normal behavior or I missed something? (In DB I have records in "active_watchers" and "watchers" tables but not in "presentity" table) ====================================================================== ====================== Module configuration: ============================= ====================================================================== #!ifdef WITH_PRESENCE loadmodule "presence.so" loadmodule "presence_xml.so" #!endif #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", DBURL) modparam("presence", "server_address", "sip:10.0.6.123:5060") # ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1) #!endif ====================================================================== ============================================================== ======================== Route: ================================ ============================================================== route[PRESENCE] { if(!is_method("PUBLISH|SUBSCRIBE")) return; #!ifdef WITH_PRESENCE if (!t_newtran()) { sl_reply_error(); exit; } if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if(is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); } exit; #!endif # if presence enabled, this part will not be executed if (is_method("PUBLISH") || $rU==$null) { sl_send_reply("404", "Not here"); exit; } return; } ================================================================ Thanks in advance Denislav Raychev Tsonev | Integration and Infrastructure Engineer | Musala Soft JSC www.musala.com | t: +359 2 969 58 21 | m: +359 878 270 965 | f: +359 2 969 58 22 World Trade Center, 36 Dragan Tsankov blvd., Sofia 1057, Bulgaria

2 1

Dispatcher on 5.2
by Igor Olhovskiy 26 Nov '18

26 Nov '18

Hi! Am I missing something or it’s a bug? Idea is following. I’m using dispatcher to load-balance calls. Using same weight destinations, order like in a file. So, dispatcher.list looks like 1 sip:172.28.11.6:5060 1 sip:172.28.11.4:5060 I’m using round-robin algo with ds_select_dst(«1», «4») But when it selects 172.28.11.4 and it for a reason not working, it will never come back to 172.28.11.6. Log: … Relaying packet du: sip:172.28.11.4:5060 … BYE/INVITE timeout with no reply … 49(59) WARNING: dispatcher [dispatch.c:2314]: ds_update_dst(): no xavp uri field in next destination record ((nil)) modparam("dispatcher", "list_file", "/tmp/kamailio/dispatcher.list") modparam("dispatcher", "flags", 2) modparam("dispatcher", "force_dst", 1) modparam("dispatcher", "ds_hash_size", 9) Kamailio: version: kamailio 5.2.0-pre0 Regards, Igor

2 3

database connections per child process
by Karthik Srinivasan 23 Nov '18

23 Nov '18

Hello, Is there a formula/algorithm that determines how many TCP connections are made per child process to a database server defined by sqlops' sqlcon parameter? ex: if i have 1 database on a database server defined by sqlcon, and i have 1 UDP child process, i notice that the child process has made 2 TCP connections to the database server. ex: if i have 3 databases on the same database server defined by 3 sqlcon statements (1 pertaining to each database) and i have 4 UDP child processes, i notice that each child process makes 4 TCP connections to the database server. ex: if i have 3 databases on the same database server defined by 3 sqlcon statements (1 pertaining to each database) and i have 6 TCP child processes, i notice that each child process makes 4 TCP connections to the database server. Basically wanting to know what governs the number of tcp connections a child process makes to a particular database server. Thank you, Karthik

3 3

IMS: SMS over IP - how to get the originator's tel address?
by Ron McLeod 22 Nov '18

22 Nov '18

I am working on a VoLTE/IMS scenario to transfer text messages as SMS over IP (+g.3gpp.smsip feature) between UE's. This is a high-level view of the message flows between the endpoints (not showing CSCFs): UE1 IP-SM-GW |---- MESSAGE (SUBMIT) --------------->| |<------------------- 202 ACCEPTED ----| | | |<-------- MESSAGE (SUBMIT_REPORT) ----| |---- 200 OK ------------------------->| | UE2 | | | |<-------------- MESSAGE (DELIVER) ----| |---- 200 OK ------------------------->| The messages does get transferred from UE1 to UE2 successfully. Since this is GSM-style SMS, the OA (originating address) and DA (destination address) are specified using telephone numbers, not sip addresses. This is not a problem for the DA, since it is specified in the SUBMIT TPDU from the originating handset, but when the IP-SM-GW sends the DELIVER TPDU it needs to specify the OA so that the recipient knows who sent the SMS, and this was not provided in the MESSAGE with the SMS-SUBMIT. According to 3GPP TS 24.341 (http://www.qtc.jp/3GPP/Specs/24341-b20.pdf): "The IP-SM-GW will have to use an address of the SM-over-IP sender that the SC can process (i.e. an E.164 number). This address will come from a tel URI in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF." Looking at the MESSAGE request sent from the S-CSCF to the IP-SM-GW, it looks like neither the P-CSCF nor the S-CSCF is providing the tel address in a P-Asserted-Identity header: MESSAGE tel:+3108012345680 SIP/2.0 Route: <sip:defaultapp@tas.core.ims1.test;lr>, <sip:iscmark@scscf.core.ims1.test:6060;lr;s=1;h=0;d=0;a=7369703a303031303330 31323334353637383940696d732e6d6e633030332e6d63633030312e336770706e6574776f72 6b2e6f7267> P-Served-User: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>;sescase=orig;regstat e=reg f: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>;tag=2703358633 t: <tel:+3108012345680> CSeq: 555874977 MESSAGE i: 2703358625_2324045032@2001:470:eb88:b021:27f:9507:589d:c201 Via: SIP/2.0/UDP [2001:470:EB88:150:0:0:0:22]:6060;branch=z9hG4bKb857.bd3345ba81ec10b1d11639d 9c7414606.0;i=a Via: SIP/2.0/TCP [2001:470:EB88:150:5054:FF:FE44:BFC9];branch=z9hG4bKb857.be53cc1c583b9c5f9dc ebf3306f2b7c1.0 v: SIP/2.0/UDP [2001:470:eb88:b021:27f:9507:589d:c201]:8906;rport=8013;branch=z9hG4bK355262 2488 Max-Forwards: 68 P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=0010300030000001 c: application/vnd.3gpp.sms Allow: MESSAGE d: no-fork User-Agent: Xiaomi_Redmi 3S_Android6.0.1_9 l: 27 P-Charging-Vector: icid-value=49565300000000511100004B01000000; icid-generated-at=2001:470:EB88:150:5054:FF:FE44:BFC9 P-Asserted-Identity: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org> P-Visited-Network-ID: core.ims1.test Message Body GSM A-I/F RP - RP-DATA (MS to Network) Message Type RP-DATA (MS to Network) RP-Message Reference RP-Message Reference: 0x05 (5) RP-Originator Address RP-Destination Address - (3108012345680) RP-User Data Length: 14 TPDU (not displayed) GSM SMS TPDU (GSM 03.40) SMS-SUBMIT 0... .... = TP-RP: TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER .0.. .... = TP-UDHI: The TP UD field contains only the short message ..1. .... = TP-SRR: A status report is requested ...0 0... = TP-VPF: TP-VP field not present (0) .... .0.. = TP-RD: Instruct SC to accept duplicates .... ..01 = TP-MTI: SMS-SUBMIT (1) TP-MR: 92 TP-Destination-Address - (8000) TP-PID: 0 TP-DCS: 0 TP-User-Data-Length: (5) depends on Data-Coding-Scheme TP-User-Data SMS text: HELLO Is this something that in configurable at the P-CSCF or the S-CSCF, or would it require now development? Thanks, Ron

2 3

issues with the debian repo for kamailio 5.2
by Aleksandar Sosic 22 Nov '18

22 Nov '18

Hi guys, I was trying to install the last 5.2 kamailio version editing the `/etc/apt/sources.list`: ``` deb http://deb.kamailio.org/kamailio52-nightly xenial main deb-src http://deb.kamailio.org/kamailio52-nightly xenial main ``` But as you can see there's only the 5.3 and 4.3 available: ``` root@e7845b3041eb:/# apt-cache madison kamailio kamailio | 5.3.0~dev0+0~20181114003826.5+xenial | http://deb.kamailio.org/kamailio52-nightly xenial/main amd64 Packages kamailio | 4.3.4-1.1ubuntu2 | http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages kamailio | 4.3.4-1.1ubuntu2 | http://archive.ubuntu.com/ubuntu xenial/universe Sources kamailio | 5.3.0~dev0+0~20181114003826.5+xenial | http://deb.kamailio.org/kamailio52-nightly xenial/main Sources ``` Any hints on how to solve this are very welcome. :) Thanks, -- Aleksandar Sosic linkedin.com/in/alexsosic/ mail: alex.sosic(a)evosip.cloud

5 6

t_set_retr and NOTIFY send after handle_publish
by Vasiliy Ganchev 21 Nov '18

21 Nov '18

Hi, list! I have a tricky problem, need advise from the community. The problem I need to solve: - have a SIP device, with a big number of BLFs configured, in some moment of time the device is slow to handle incoming SIP messages (a lot of NOTIFYs received), kamailio start retransmitting NOTIFYs, and the device get stuck. My idea is to change retransmits timeout for NOTIFYs that are sent out after handle_publish, so if get stuck, not to make "DoS" I have. What I tried: - t_set_retr(5000, 10000); before handle_publish => does not work - my tm is compiled with DTM_DIFF_RT_TIMEOUT, and t_set_retr works for e.g. INVITEs I have read the mailing list and also studied sources of presence and tm modules. I see that at the moment there is no way to solve what I want from config. My next steps are going to make some hacks in C code... at least to understand the code better and find some new insights Any other ideas? Comments/ideas are highly welcomed! cheers -- Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html

2 3

Closing all ws connections
by Andrey Deykunov 21 Nov '18

21 Nov '18

Hi guys, I've implemented an rpc call that closes all WS connections: void ws_rpc_close_all(rpc_t *rpc, void *ctx) { ws_connection_t **list = NULL, **list_head = NULL; ws_connection_t *wsc = NULL; int ret; list_head = wsconn_get_list(); if(!list_head) return; list = list_head; wsc = *list_head; while(wsc) { LM_WARN("Closing connection\n"); ret = close_connection(&wsc, LOCAL_CLOSE, 1000, str_status_normal_closure); wsc = *(++list); } wsconn_put_list(list_head); } Please take a look. Can I call close_connection() and perform list iterations in this function not using WSCONN_LOCK? Thanks, Andrey

3 2

from Asterisk to Kamailio
by Valter Nogueira 21 Nov '18

21 Nov '18

Today, I use Asterisk as a SIP/RTP PROXY I proxy from customers Asterisks to a VOIP provider, in a multi-homed server. Now, I want to move to Kamailio without any rupture in customer's configuration. As anyone can imagine I am kind of lost. USER ACCOUNTS In Asterisk, I create a dynamic host account named ACCOUNT1 and I receive in *FROM HEADER sip:ACCOUNT1@customer_ip_address* In Kamailio, I have to define the account's domain like *kamctl add ACCOUNT1(a)mydomain.com <ACCOUNT1(a)mydomain.com> password. *Kamailio just accepts a REGISTER/INVITE from *ACCOUNT1(a)mydomain.com <ACCOUNT1(a)mydomain.com>* SIP/RTP PROXY In Asterisk, I just dialout to the VOIP PROVIDER like *dial (SIP/VOIP_ACCOUNT/${EXTENSION})* Asterisk does all the magic (it is a B2BUA). It bridges the new call and media to the original call. Moreover, user don't know anything about how call are completed, nor how credentials are setup and soon. In Kamailio, I guess that I have to use nat, tm and rtpproxy modules and maybe uac. I am not sure how to setup it. Can someone send me a clue? Thank you, Valter

4 7

Kamailio-5.1.6 Crash
by Hamid Hashmi 20 Nov '18

20 Nov '18

I have been using the following version of kamailio Version: kamailio 5.1.6 (x86_64/linux) Default config: /usr/local/etc/kamailio/kamailio.cfg Default paths to modules: /usr/local/lib64/kamailio/modules Compile flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES MAX_RECV_BUFFER_SIZE=262144 MAX_URI_SIZE=1024 BUF_SIZE=65535 DEFAULT PKG_SIZE=8MB DEFAULT SHM_SIZE=64MB ADAPTIVE_WAIT_LOOPS=1024 TCP poll methods: poll, epoll_lt, epoll_et, sigio_rt, select Source code revision ID: unknown Compiled with: gcc 4.8.5 Compiled on: 11:48:33 Oct 11 2018 and I noticed today that the Kamailio service is crashing. [root@kamailiostandby /]# gdb core.17805 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... [New LWP 17805] Core was generated by `/usr/local/sbin/kamailio -P /run/kamailio/kamailio.pid -f /usr/local/SIP'. Program terminated with signal 11, Segmentation fault. #0 0x00007f636559e54b in ?? () "/core.17805" is a core file. Please specify an executable to debug. (gdb) list No symbol table is loaded. Use the "file" command. (gdb) bt #0 0x00007f636559e54b in ?? () #1 0x00007f63a9571810 in ?? () #2 0x0000000000000000 in ?? () Regards Hamid R. Hashmi

2 3

registrar::save() does not save 'received' field of the 'location' table
by Andrey Deykunov 20 Nov '18

20 Nov '18

Hi, We deploy kamailio in the cluster containing two nodes (Active and Passive). When Active node becomes Passive, our websocket clients continue sending REGISTER to this node. Passive node routes these requests to the Active node through the UDP, that causes the following warning message: 2018-11-14T04:43:31.070005-08:00 qapbx-ca1-1 kamailio[25597]: WARNING: <core> [core/forward.c:231]: get_send_socket2(): protocol/port mismatch (forced udp:64.78.52.88:5060, to ws:10.9.3.116:20033) Every registered client should be stored in the 'location': $var(save_val) = save("location", 0, "sip:$au@$td"); if ($var(save_val) <= 0) { xlog("L_ERR", "[$fU,R,$ci]: Registration saving failed, contact $ct"); sl_reply_error(); } else if ($var(save_val) == 3) { xlog("L_INFO", "[$fU,R,$ci]: Unregistration accepted. Login: $fU; ua: $ua; s-ip: $si; s-port: $sp; 3d parm: sip:$au@$td"); } else { xlog("L_INFO", "[$fU,R,$ci]: Registration accepted. Login: $fU; ua: $ua; s-ip: $si; s-port: $sp; 3d parm: sip:$au@$td"); } Log output of the Avtive node: 2018-11-14T04:43:31.063376-08:00 qapbx-ca1-2 kamailio[24722]: INFO: <script>: [54004221,R,ibca3ujmr0q81nn0l5puen]: REGISTER received with R-URI: sip:64.78.52.90, ct: <sip:vu2o757j@si7ofk7i8cs7.invalid;transport=ws>;+sip.ice; reg-id=1;+sip.instance="<urn:uuid:00ff4c8d-2a5e-4614-b80a-d7c14c0e41e3>";expires=600, cseq=1, s-ip: 64.78.52.88, s-port: 5060 2018-11-14T04:43:31.063947-08:00 qapbx-ca1-2 kamailio[24722]: INFO: <script>: Our node is active 2018-11-14T04:43:31.064323-08:00 qapbx-ca1-2 kamailio[24722]: INFO: <script>: [54004221,R,ibca3ujmr0q81nn0l5puen]: Authorization headers are empty in REGISTER command. Send 401 Unauthorized to 64.78.52.88 2018-11-14T04:43:31.285967-08:00 qapbx-ca1-2 kamailio[24716]: INFO: <script>: [54004221,R,ibca3ujmr0q81nn0l5puen]: REGISTER received with R-URI: sip:64.78.52.90, ct: <sip:vu2o757j@si7ofk7i8cs7.invalid;transport=ws>;+sip.ice; reg-id=1;+sip.instance="<urn:uuid:00ff4c8d-2a5e-4614-b80a-d7c14c0e41e3>";expires=600, cseq=2, s-ip: 64.78.52.88, s-port: 5060 2018-11-14T04:43:31.286564-08:00 qapbx-ca1-2 kamailio[24716]: INFO: <script>: Our node is active 2018-11-14T04:43:31.286943-08:00 qapbx-ca1-2 kamailio[24716]: INFO: <script>: [54004221,R,ibca3ujmr0q81nn0l5puen]: Registration accepted. Login: 54004221; ua: JsSIP 3.2.11; s-ip: 64.78.52.88; s-port: 5060; 3d parm: sip:54004221@qapbx-ca1.qaserverdata.net but in this scenario the save() method stores null value in the 'received' row. How can I fix it? Thank you, Andrey

2 1

RTPengine: shouldn't SDP <sess-version> be incremented when SDP is updated in-dialog?
by George Diamantopoulos 20 Nov '18

20 Nov '18

Hello all, I have the following issue (I think) with RTP engine. An INVITE comes in, and rtpengine will rewrite the SDP accordingly, as configured in kamailio.cfg. After some time a reINVITE is sent out in the opposite direction, for session refresh purposes. As I use rtcp-mux-offer in kamailio.cfg for this direction, RTPengine will inject the rtcp-mux parameter, and this reINVITE is forwarded to the UAC that sent the original INVITE. However, the SDP in the reINVITE is exactly the same as the SDP in the 200 OK to the original INVITE, with the exception of the rtcp-mux parameter. Since the SDP offered from the same end has changed, shouldn't session version be incremented as well? Does this sound like something that should be reported as a bug to rtpengine? Or am I missing something here? Thanks! Best regards, George Diamantopoulos

3 4

Number of sql connections
by Duarte Rocha 19 Nov '18

19 Nov '18

Greetings, I have my core parameter listen like this : listen=udp:eth0 children=12 Like this and the other settings, my kamailio has 21 threads and 20 Sql connections. If I add more listens, listen=udp:eth0 listen=udp:eth0:5072 listen=udp:eth0:5074 Now I have 45 threads and 45 Sql connections. Why does this happen and can i set a a number of threads and/or sql connections that doesn't change with the number of "listen" parameters that i have ? Best Regards, Duarte Rocha

3 2

recording audio stream
by bill＠telopar.net 18 Nov '18

18 Nov '18

Hi All: I have a project that requires that I record the audio streams from an ongoing phone call. It seems that rtp_proxy module should do that, but I can't seem to get it to work. My config file: *if(nat_uac_test("8")) { //rtpproxy_manage("co"); xlog("L_INFO", "rtpproxy Call is going to private IPv4 Media Server Engage RTPProxy Now\n"); rtpproxy_manage("crwie","10.1.1.2"); } else { //rtpproxy_manage("cor"); xlog("L_INFO", "rtpproxy Call is coming from a private IPv4 Media Server Engage RTPProxy Now\n"); rtpproxy_manage("crwei","10.1.1.2"); } *There appears to be conversations going on with rtpproxy on both legs of the call. But I seem to be missing the step that records the audio*. *Anybody have an example of how to do this. TIA, Bill **

4 3

Which algorithm to use as load-balance
by David Villasmil 16 Nov '18

16 Nov '18

Hello, Is it possible to set an algorithm like the following? fs1 - Priority 10 - maxload 20 calls fs2 - Priority 10 - maxload 20 calls fs3 - Priority 9 - maxload 20 calls fs4 - Priority 8 - maxload 20 calls fs5 - Priority 7 - maxload 20 calls So that, whenever any new call comes in, fs1 and fs2 would be used, meaning the fs with the highest priority would be use UNLESS there's 20 calls on that server, in which case, the next server with the highest priority would be used. Thanks!, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

2 7

Freeradiusclient Interim-Update Support
by Hamid Hashmi 16 Nov '18

16 Nov '18

Dear All Is module acc_radius supports interim updates? If yes then how to configure it. Regards Hamid R. Hashmi

2 3

textops module get_body_part function gives boundary error even if not multipart
by YAS0 CANER 16 Nov '18

16 Nov '18

Hello, i try to get content from Invite request but it gives boundary error. it is not multipart or mixed content but it checks boundary and gives error. Thanks. My message INVITE Content-Type: application/resource-lists+xml <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list> <entry uri="100?Call-ID=$calli&From=$fromtag&To=$toTag&Session-ID=1"/> <entry uri="103?Call-ID=$calli2&From=$fromtag2&To=$toTag2&Session-ID=2"/> </list> </resource-lists> static int ki_get_body_part_helper(sip_msg_t* msg, str* ctype, pv_spec_t *dst, int mode) { ... if(get_boundary(msg, &boundary)!=0) { LM_ERR("Cannot get boundary. Is body multipart?\n"); return -1; } .... int get_boundary(struct sip_msg* msg, str* boundary) params.s = memchr(msg->content_type->body.s, ';',msg->content_type->body.len); if (params.s == NULL) { LM_INFO("Content-Type hdr has no params <%.*s>\n", msg->content_type->body.len, msg->content_type->body.s); return -1; }

1 0

signal 15 received and .. on Kamailio 5.1.6
by AL RSM 16 Nov '18

16 Nov '18

Hi, I just installed Kamailio 5.1.6 on Ubuntu 18.04. Starting Kamailio with the default config will give us the following in the log. Is this normal? Is there a way to fix this issue? Thanks, AL Nov 15 14:01:59 lab-proxy03 kamailio[13544]: * Stopping Kamailio SIP Server: kamailio Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5182]: NOTICE: <core> [main.c:692]: handle_sigs(): Thank you for flying kamailio!!! Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5213]: INFO: <core> [main.c:819]: sig_usr(): signal 15 received Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5212]: INFO: <core> [main.c:819]: sig_usr(): signal 15 received .... Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5182]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Nov 15 14:02:00 lab-proxy03 kamailio[13544]: ...done. Nov 15 14:02:00 lab-proxy03 kamailio[13556]: * Starting Kamailio SIP Server: kamailio Nov 15 14:02:00 lab-proxy03 kamailio: INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Nov 15 14:02:00 lab-proxy03 kamailio: INFO: <core> [core/tcp_main.c:4721]: init_tcp(): using epoll_lt as the io watch method (auto detected) .... Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: rr [rr_mod.c:175]: mod_init(): outbound module not available Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:205]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:205]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13618]: INFO: jsonrpcs [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/13618 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13619]: INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) Nov 15 14:02:00 lab-proxy03 kamailio[13556]: ...done.

2 1

priority load balance
by David Villasmil 15 Nov '18

15 Nov '18

Hello, Trying to do priority load balancing (8) but i'm getting an error `unable to update destination load - classic dispatching` anyone knows why? i've got ```modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "flags", 2) modparam("dispatcher", "dst_avp", "$avp(AVP_DST)") modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)") modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)") modparam("dispatcher", "dstid_avp", "$avp(dsdstid)") modparam("dispatcher", "attrs_avp", "$avp(dsattrs)")``` Looking at the code, dstid_avp would be null, but not sure why? I have set in the table the priorities as 10 for 2 gws (edited) Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

2 1

"signal 15 received" and ... on Kamailio 5.1.6
by AL RSM 15 Nov '18

15 Nov '18

Hi, I just installed Kamailio 5.1.6 on Ubuntu 18.04. Starting Kamailio with the default config will give us the following in the log. Is this normal? Is there a way to fix this issue? Thanks, AL Nov 15 14:01:59 lab-proxy03 kamailio[13544]: * Stopping Kamailio SIP Server: kamailio Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5182]: NOTICE: <core> [main.c:692]: handle_sigs(): Thank you for flying kamailio!!! Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5213]: INFO: <core> [main.c:819]: sig_usr(): signal 15 received Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5212]: INFO: <core> [main.c:819]: sig_usr(): signal 15 received .... Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5182]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Nov 15 14:02:00 lab-proxy03 kamailio[13544]: ...done. Nov 15 14:02:00 lab-proxy03 kamailio[13556]: * Starting Kamailio SIP Server: kamailio Nov 15 14:02:00 lab-proxy03 kamailio: INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Nov 15 14:02:00 lab-proxy03 kamailio: INFO: <core> [core/tcp_main.c:4721]: init_tcp(): using epoll_lt as the io watch method (auto detected) .... Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: rr [rr_mod.c:175]: mod_init(): outbound module not available Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:205]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:205]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13618]: INFO: jsonrpcs [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/13618 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13619]: INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) Nov 15 14:02:00 lab-proxy03 kamailio[13556]: ...done.

1 0

REFER packet - Kamailio gives request_uri instead request-uri -
by YAS0 CANER 15 Nov '18

15 Nov '18

Hello, i test on refer packet on Kamailio 5.3-dev . it gives route_uri (@route_uri) instead of request-uri ($ru). Could you give me help about it please. Thanks. Packet 2018/11/15 10:51:20.522512 192.168.1.109:5080 -> 192.168.1.120:5060 REFER sip:100@192.168.1.120 SIP/2.0 CSeq: 1 REFER From: <sip:105@192.168.1.120;transport=UDP>;tag=10215SIPpTag001 To: <sip:100@192.168.1.120;transport=UDP>;tag=7e3fb504 Call-ID: 1-10215(a)192.168.1.109 Max-Forwards: 70 Route: <sip:192.168.1.120;lr> Via: SIP/2.0/UDP 192.168.1.136:5080;branch=z9hG4bK-10215-1-7 Contact: <sip:105@192.168.1.136:5080> Refer-To: <sip:103@192.168.1.120> Referred-By: <sip:105@192.168.1.120;transport=UDP> Content-Length: 0 1(48532) WARNING: {1 1 REFER 1-10215(a)192.168.1.109} <script>: REFER in WITHINDLG [$ru sip:192.168.1.120;lr ] 1(48532) WARNING: {1 1 REFER 1-10215(a)192.168.1.109} <script>: REFER MYROUTE [ru sip:192.168.1.120;lr ] [route_uri sip:192.168.1.120;lr ] [ rU <null> ] Scenairo SIPP UAC -> Kamailio - > UAC 2 After call answered , SIPP send REFER request as above.

1 2

mod siptrace - option ping from nathelper do not get duplicated
by Roman Dissauer 14 Nov '18

14 Nov '18

Hi, we are using kamailio 5.1 with siptrace module in trace_mode on. Everything works perfect except that option pings from nathelper module do not get duplicated. Is there a reason for that? Thanks, Roman

2 1

Core dump on diameter CCR request
by Venkatesh Macha 14 Nov '18

14 Nov '18

Hi all, I am trying to implement Diameter charging with Kamailio. I am following below tutorial https://www.kamailio.org/events/2016-KamailioWorld/Day2/15-Carsten.Bock-Dia… But whenever I try to do the Ro_CCR from the INVITE block, Kamailio is crashing and generating the core dump. I am new to diameter. I might be doing something wrong here. please someone help me here. Please find the *diameter.xml* and *Diameter_core_dump_full_debug.txt* file. diameter.xml <http://sip-router.1086192.n5.nabble.com/file/t6374/diameter.xml> Diameter_core_dump_full_Debug.txt <http://sip-router.1086192.n5.nabble.com/file/t6374/Diameter_core_dump_full_…> Here is my kamailio.cfg : loadmodule "cdp" loadmodule "cdp_avp" loadmodule "ims_charging" loadmodule "ims_dialog" modparam("cdp","config_file","/etc/kamailio/diameter.xml") modparam("cdp", "debug_heavy", 1) # ----- ims_diameter_ro params ----- #modparam("ims_charging", "single_ro_session_per_dialog", 1) modparam("ims_charging", "origin_host", "10.195.0.38"); modparam("ims_charging", "origin_realm", "10.195.0.38"); modparam("ims_charging", "destination_realm", "mydomain.com"); modparam("ims_charging","interim_update_credits",30); modparam("ims_charging","timer_buffer",5); # -- ims_dialog params -- modparam("ims_dialog", "dlg_flag", 8) While starting the kamailio, i am getting following errors: Nov 11 11:40:03 ip-10-195-0-38 /usr/local/sbin/kamailio[25653]: ERROR: cdp [peerstatemachine.c:675]: add_peer_application(): Too many applications for this peer (max 0), not adding Application 4:0. Before crashing kamailio showing following error: Nov 11 11:39:49 ip-10-195-0-38 /usr/local/sbin/kamailio[25571]: INFO: {1 18325 INVITE Nf6-dl2WeXF.LJhXotiRsuMhijsNx45o} <script>: Entered into INVITE Block Nov 11 11:39:49 ip-10-195-0-38 /usr/local/sbin/kamailio[25571]: ERROR: {1 18325 INVITE Nf6-dl2WeXF.LJhXotiRsuMhijsNx45o} ims_dialog [dlg_handlers.c:264]: dlg_get_iuid_shm_clone(): ***** Requesting 8 Nov 11 11:39:49 ip-10-195-0-38 /usr/local/sbin/kamailio[25571]: CRITICAL: {1 18325 INVITE Nf6-dl2WeXF.LJhXotiRsuMhijsNx45o} <core> [core/mem/q_malloc.c:144]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(0, abcdefed)[0x7f467d438768:0x7f467d4387a0]! Memory allocator was called from cdp: diameter_avp.c:157. Fragment marked by cdp: peerstatemachine.c:602. Exec from core/mem/q_malloc.c:384. Nov 11 11:39:49 ip-10-195-0-38 /usr/local/sbin/kamailio[25599]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 16 Nov 11 11:39:52 ip-10-195-0-38 /usr/local/sbin/kamailio[25567]: ALERT: <core> [main.c:740]: handle_sigs(): child process 25571 exited by a signal 6 Nov 11 11:39:52 ip-10-195-0-38 /usr/local/sbin/kamailio[25567]: ALERT: <core> [main.c:743]: handle_sigs(): core was generated Nov 11 11:39:52 ip-10-195-0-38 /usr/local/sbin/kamailio[25567]: INFO: <core> [main.c:766]: handle_sigs(): terminating due to SIGCHLD Thanks you in Advance, Venkey -- Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html

4 9

WebRTC video call terminated after ~30 seconds
by Mathias Brodala - Pagemachine AG 14 Nov '18

14 Nov '18

Hi, I am currently testing a setup to do video calls via WebRTC and have set up Kamailio as SIP server. So far the calls are working fine, but after around 30 seconds the calls are terminated. I can reproduce this easily both with the JsSIP demo [0] as well as the SIPjs demo [1]. The browser console using JsSIP log [2] shows me this: > JsSIP:WebSocketInterface WebSocket wss://sip.example.org closed +60s > jssip-3.2.10.js:23490 JsSIP:WebSocketInterface WebSocket abrupt disconnection +1ms Please also have a look at my kamailio.cfg [3]. I tried to follow the docs of the websocket module [4] as close as possible to get everything up and running. Kamailio is currently running on a private DigitalOcean droplet and I already tried to disable all firewall rules without change. I also asked the DO staff if something could lead to UDP packets getting dropped after some time but I was told that there is no such logic in the DO network. Please let me know if you can find anything unusual which could cause this behavior or if you need more information. Thank you, Mathias Brodala [0] https://tryit.jssip.net/ [1] https://sipjs.com/demo-phone/ [2] https://gist.github.com/mbrodala/0f81aaa174be87096cf20502633f3ac3 [3] https://gist.github.com/mbrodala/066faa455da46362dab3dd5326ba8ad1 [4] https://www.kamailio.org/docs/modules/5.1.x/modules/websocket.html -- Dipl.-Inf. (FH) Mathias Brodala Tel.: 069.260.99.70.45 Fax: .31 mbrodala(a)pagemachine.de <https://www.pagemachine.de/> Pagemachine AG Solmsstraße 6a, 60486 Frankfurt am Main <https://maps.google.com/?q=Solmsstra%C3%9Fe+6a,+60486+Frankfurt+am+Main&ent…> Vorstand: Volker Neuenhaus, Stefan Schütt, Miklos Weiszhaupt Vorsitzender des Aufsichtsrats: Holger Kleinschmidt Registergericht: Amtsgericht Frankfurt Registernummer: HRB 56436 Umsatzsteuer-ID: DE226286966 <https://www.kununu.com/de/pagemachine> <https://www.kununu.com/de/pagemachine> <http://www.frankfurt-main.ihk.de/> <https://typo3.com/>

2 1

topos without db?
by Giuseppe Pandolfi 13 Nov '18

13 Nov '18

Hi, Is it possible using topos module without db support? I'm trying to use topos module with sqlite db backend, but I have any concurrency problems during write procedure (I use WALL pragma). When execute speed calls traffic sqlite emits an error trace telling it's locked. Is it possible to use a sort of hash tabel to save topos informations and don't use the db? Best regards, Giuseppe

5 4

variable $rb not updated on failure route after a 302 on the same PID
by David Escartín 13 Nov '18

13 Nov '18

Hello all we are seeing what we think is quite strange behaviour We have expecienced this on 5.0 and 5.1 version. this is the call flow INV--> <-- 302 (SDP) INV--> <-- 503 (SDP) (or another 302) When we receive a 302 and we load contacts and create a new branch, when we receive the second error response, and we receive it on the same udp receiver process, if we read the content of $rb on the the onreply_route, we get the proper value of the response SDP, but when we read $T_rpl($rb) on the failure_route, we get the value of the first error transaction. If the response (second) is received in another PID, it's ok. I'm not sure if i'm explaining myself, but we would think that the value should be updated, no matter which PID is used to process the response for example, running the kamailio with only 1 child. For the first 302 we have onreply route checking $rb 1(7698) INFO: <script>: LAL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} failure_route checking $T_rpl($rb) 1(7698) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} and for the next error 1(7698) INFO: <script>: LAL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 1(7698) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} If we run it with 16 children and the PID don't match. For the first 302 we have onreply route checking $rb 13(8360) INFO: <script>: LAL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} failure_route checking $T_rpl($rb) 13(8360) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} and for the next error after loading the contacts 15(8362) INFO: <script>: LAL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 15(8362) INFO: <script>: LOOOOOOOOL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} i attach you the logs in both cases could you please check if you see anything wrong? best regards david 16_children.log 11(8358) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/634) [[INVITE sip:34606147628@10.100.10.67:5069 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-]] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 11(8358) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <INVITE> 11(8358) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5069> 11(8358) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 11(8358) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 11(8358) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 11(8358) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 11(8358) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 11(8358) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 11(8358) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 11(8358) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 11(8358) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 11(8358) INFO: <script>: hereeeeeeeeeee 11(8358) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=1 , global msg id=0 , T on entrance=0xffffffffffffffff 11(8358) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=217 11(8358) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 11(8358) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=13774, isACK=0 11(8358) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 11(8358) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 11(8358) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=9680SIPpTag001 11(8358) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 11(8358) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 56115a2d09f62d466f1d45a5f5ff7cc2 11(8358) DEBUG: tm [t_funcs.c:324]: t_relay_to(): new INVITE 11(8358) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 11(8358) DEBUG: tm [t_reply.c:596]: _reply_light(): reply sent out. buf=0x7f334b5f4ea0: SIP/2.0 100 trying -..., shmem=0x7f3346638240: SIP/2.0 100 trying - 11(8358) DEBUG: tm [t_reply.c:606]: _reply_light(): finished 11(8358) INFO: <script>: LEL 11(8358) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 11(8358) INFO: <script>: hereeeeeeeeeee 11(8358) DEBUG: tm [t_funcs.c:372]: t_relay_to(): new transaction forwarded 11(8358) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 550 usec 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 11(8358) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 11(8358) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/397) [[SIP/2.0 100 Trying 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5f]] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 11(8358) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 11(8358) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <100> 11(8358) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Trying> 11(8358) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.0>; state=9 11(8358) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 11(8358) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 11(8358) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 11(8358) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 11(8358) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 11(8358) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 11(8358) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 11(8358) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 11(8358) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=1 T start=0xffffffffffffffff 13(8360) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/479) [[SIP/2.0 302 Moved Temporarily 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d]] 11(8358) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 0 11(8358) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 11(8358) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=2 T end=0x7f334663b040 11(8358) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[0]=0 local=0 is_invite=1) 11(8358) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 11(8358) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 11(8358) INFO: <script>: LAL 11(8358) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=100 11(8358) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=-1 icode=0 11(8358) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 149 usec 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 11(8358) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 13(8360) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 13(8360) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <302> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Moved Temporarily> 13(8360) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.0>; state=9 13(8360) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 13(8360) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 13(8360) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 13(8360) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 13(8360) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 13(8360) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 13(8360) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 13(8360) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 13(8360) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 13(8360) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 13(8360) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 13(8360) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=0 T start=0xffffffffffffffff 13(8360) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 0 13(8360) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 13(8360) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=1 T end=0x7f334663b040 13(8360) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[0]=100 local=0 is_invite=1) 13(8360) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=63 13(8360) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 13(8360) INFO: <script>: LAL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 13(8360) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=302 13(8360) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 13(8360) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <302> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Moved Temporarily> 13(8360) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.0>; state=9 13(8360) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 13(8360) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 13(8360) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 13(8360) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 13(8360) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 13(8360) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 13(8360) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 13(8360) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 13(8360) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 13(8360) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=63 13(8360) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 13(8360) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 13(8360) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f3346637088) id=0 global id=0 T start=0x7f334663b040 13(8360) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7f334663b040) already found for msg (0x7f3346637088)! 13(8360) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <302> 13(8360) INFO: <script>: Call: 302 received, trying to load contacts 13(8360) DEBUG: uac_redirect [rd_funcs.c:72]: get_redirect(): resume branch=0 13(8360) DEBUG: uac_redirect [rd_funcs.c:79]: get_redirect(): checking branch=0 (added=0) 13(8360) DEBUG: uac_redirect [rd_funcs.c:83]: get_redirect(): branch=0 is a redirect (added=0) 13(8360) DEBUG: uac_redirect [rd_funcs.c:159]: sort_contacts(): sort_contacts: <sip:34666988297@10.100.10.67:5060> q=10 13(8360) DEBUG: uac_redirect [rd_funcs.c:295]: shmcontact2dset(): adding contact <sip:34666988297@10.100.10.67:5060> 13(8360) DEBUG: <core> [sruid.c:183]: sruid_next(): new sruid is [rdir-5be4236b-20a8-1] (1 / 20) 13(8360) DEBUG: tm [t_serial.c:191]: ki_t_load_contacts(): nr_branches is 1 13(8360) DEBUG: tm [t_serial.c:194]: ki_t_load_contacts(): nothing to do - only one contact! 13(8360) INFO: <script>: LEL 13(8360) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 13(8360) INFO: <script>: hereeeeeeeeeee 13(8360) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=-1 icode=0 13(8360) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 783 usec 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 13(8360) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 14(8361) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/397) [[SIP/2.0 100 Trying 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5f]] 15(8362) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/482) [[SIP/2.0 503 Service Unavailable 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f6]] 14(8361) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 14(8361) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 14(8361) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <100> 14(8361) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Trying> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 15(8362) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <503> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Service Unavailable> 14(8361) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.1>; state=9 14(8361) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 14(8361) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 14(8361) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 14(8361) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 14(8361) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.1>; state=9 15(8362) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 15(8362) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 14(8361) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 15(8362) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 14(8361) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 14(8361) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 14(8361) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 14(8361) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 15(8362) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 14(8361) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=0 T start=0xffffffffffffffff 14(8361) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 1 14(8361) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 14(8361) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=1 T end=0x7f334663b040 15(8362) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 14(8361) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[1]=0 local=0 is_invite=1) 15(8362) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 15(8362) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=0 T start=0xffffffffffffffff 15(8362) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 1 15(8362) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 14(8361) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 15(8362) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=1 T end=0x7f334663b040 15(8362) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[1]=100 local=0 is_invite=1) 14(8361) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 14(8361) INFO: <script>: LAL 14(8361) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=100 14(8361) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=1, save=0, relay=-1 icode=0 14(8361) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 199 usec 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 14(8361) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 15(8362) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=64 15(8362) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 15(8362) INFO: <script>: LAL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 15(8362) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=503 15(8362) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 15(8362) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <503> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Service Unavailable> 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.1>; state=9 15(8362) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 15(8362) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 15(8362) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 15(8362) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 15(8362) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=64 15(8362) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 15(8362) INFO: <script>: LOOOOOOOOL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 15(8362) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f3346637088) id=0 global id=0 T start=0x7f334663b040 15(8362) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7f334663b040) already found for msg (0x7f3346637088)! 15(8362) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <503> 15(8362) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f3346637088) id=0 global id=0 T start=0x7f334663b040 15(8362) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7f334663b040) already found for msg (0x7f3346637088)! 15(8362) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <503> 15(8362) INFO: <script>: LEL 15(8362) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 15(8362) INFO: <script>: hereeeeeeeeeee 15(8362) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=1, save=0, relay=-1 icode=0 15(8362) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 676 usec 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 15(8362) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 15(8362) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/404) [[SIP/2.0 180 Ringing 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5]] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 15(8362) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <180> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Ringing> 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.2>; state=9 15(8362) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 15(8362) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 15(8362) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 15(8362) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 15(8362) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 15(8362) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 15(8362) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=1 T start=0xffffffffffffffff 6(8353) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/595) [[SIP/2.0 200 OK 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7]] 15(8362) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 2 15(8362) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 15(8362) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=2 T end=0x7f334663b040 15(8362) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[2]=0 local=0 is_invite=1) 15(8362) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 15(8362) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 15(8362) INFO: <script>: LAL 15(8362) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=180 15(8362) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=2, save=0, relay=2 icode=0 15(8362) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 404, new size: 318 15(8362) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:112, new: 26, rest: 292 msg= SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-9680-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=9680SIPpTag001 To: "Javi" <sip:34606147628@10.100.10.67:5069>;tag=5 Call-ID: 1-9680(a)10.100.10.67 CSeq: 1 INVITE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Length: 0 15(8362) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 71 usec 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 15(8362) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 6(8353) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 6(8353) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 6(8353) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <200> 6(8353) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <OK> 6(8353) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.2>; state=9 6(8353) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 6(8353) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 6(8353) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 6(8353) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 6(8353) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 6(8353) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 6(8353) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 6(8353) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 6(8353) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 6(8353) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=0 T start=0xffffffffffffffff 6(8353) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 2 6(8353) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 6(8353) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=1 T end=0x7f334663b040 6(8353) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=180, uac[2]=180 local=0 is_invite=1) 6(8353) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=161 6(8353) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 6(8353) INFO: <script>: LAL v=0 o=user1 53655765 2353687637 IN IP4 10.100.10.67 s=- c=IN IP4 10.100.10.67 t=0 0 m=audio 6000 RTP/AVP 0 18 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 6(8353) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=180, new_code=200 6(8353) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=2, save=0, relay=2 icode=0 6(8353) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 595, new size: 509 6(8353) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:107, new: 21, rest: 488 msg= SIP/2.0 200 OK Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-9680-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=9680SIPpTag001 To: "Javi" <sip:34606147628@10.100.10.67:5069>;tag=5 Call-ID: 1-9680(a)10.100.10.67 CSeq: 1 INVITE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Type: application/sdp Content-Length: 161 v=0 o=user1 53655765 2353687637 IN IP4 10.100.10.67 s=- c=IN IP4 10.100.10.67 t=0 0 m=audio 6000 RTP/AVP 0 18 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 6(8353) DEBUG: tm [t_reply.c:1631]: cleanup_uac_timers(): RETR/FR timers reset 6(8353) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 283 usec 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 6(8353) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 6(8353) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/323) [[ACK sip:34606147628@10.100.10.67:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-968]] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 6(8353) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <ACK> 6(8353) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5060> 6(8353) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 6(8353) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 6(8353) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 6(8353) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 6(8353) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 6(8353) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 6(8353) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 6(8353) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <ACK> 6(8353) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-9680(a)10.100.10.67] - cseq: [1 ACK] 6(8353) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 6(8353) DEBUG: sl [sl_funcs.c:387]: sl_filter_ACK(): too late to be a local ACK! 6(8353) INFO: <script>: hereeeeeeeeeee 6(8353) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=2 , global msg id=1 , T on entrance=0xffffffffffffffff 6(8353) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 6(8353) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 6(8353) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=13774, isACK=1 6(8353) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 6(8353) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 6(8353) DEBUG: tm [t_funcs.c:284]: t_relay_to(): forwarding ACK statelessly 6(8353) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 56115a2d09f62d466f1d45a5f5ff7cc2 6(8353) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 6(8353) DEBUG: <core> [core/forward.c:557]: forward_request(): Sending: ACK sip:34606147628@10.100.10.67:5060 SIP/2.0 Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.0 Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-9680-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=9680SIPpTag001 To: "Test" <sip:34606147628@10.100.10.67:5069>;tag=5 Call-ID: 1-9680(a)10.100.10.67 CSeq: 1 ACK Max-Forwards: 70 Subject: 1 Content-Length: 0 . 6(8353) DEBUG: <core> [core/forward.c:559]: forward_request(): orig. len=323, new_len=414, proto=1 6(8353) INFO: <script>: hereeeeeeeeeee 6(8353) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 232 usec 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 6(8353) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 3(8350) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/338) [[BYE sip:34606147628@10.100.10.67:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-968]] 3(8350) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 3(8350) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <BYE> 3(8350) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5060> 3(8350) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 3(8350) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-8>; state=16 3(8350) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 3(8350) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 3(8350) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 3(8350) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 3(8350) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 3(8350) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 3(8350) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 3(8350) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <2> <BYE> 3(8350) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-9680(a)10.100.10.67] - cseq: [2 BYE] 3(8350) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 3(8350) INFO: <script>: hereeeeeeeeeee 3(8350) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=2 , global msg id=1 , T on entrance=0xffffffffffffffff 3(8350) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 3(8350) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 3(8350) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=13771, isACK=0 3(8350) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 3(8350) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 3(8350) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 5b69d64cadac24fd6fc477c074a9b4c9 3(8350) INFO: <script>: LEL 3(8350) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 3(8350) INFO: <script>: hereeeeeeeeeee 3(8350) DEBUG: tm [t_funcs.c:372]: t_relay_to(): new transaction forwarded 3(8350) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 265 usec 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 3(8350) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 7(8354) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/396) [[SIP/2.0 200 OK 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKbc53.5b69d64cadac24fd6fc477c074a9b]] 7(8354) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 7(8354) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 7(8354) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <200> 7(8354) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <OK> 7(8354) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKbc53.5b69d64cadac24fd6fc477c074a9b4c9.0>; state=9 7(8354) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 7(8354) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-8>; state=16 7(8354) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 7(8354) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 7(8354) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 7(8354) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 7(8354) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 7(8354) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 7(8354) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 7(8354) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <2> <BYE> 7(8354) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [2 BYE] 7(8354) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=1 T start=0xffffffffffffffff 7(8354) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13771 label 0 branch 0 7(8354) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f33466359d8)! 7(8354) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=2 T end=0x7f33466359d8 7(8354) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=0, uac[0]=0 local=0 is_invite=0) 7(8354) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=200 7(8354) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=0 icode=0 7(8354) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 396, new size: 310 7(8354) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:107, new: 21, rest: 289 msg= SIP/2.0 200 OK Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-9680-1-8 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=9680SIPpTag001 To: "Test" <sip:34606147628@10.100.10.67:5069>;tag=5 Call-ID: 1-9680(a)10.100.10.67 CSeq: 2 BYE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Length: 0 7(8354) DEBUG: tm [t_reply.c:1631]: cleanup_uac_timers(): RETR/FR timers reset 7(8354) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 137 usec 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 7(8354) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 18(8365) DEBUG: tm [h_table.c:129]: free_cell_helper(): freeing transaction 0x7f334663b040 from timer.c:654 18(8365) DEBUG: tm [h_table.c:129]: free_cell_helper(): freeing transaction 0x7f33466359d8 from timer.c:654 1_children.log 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/634) [[INVITE sip:34606147628@10.100.10.67:5069 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 1(7698) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <INVITE> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5069> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=1 , global msg id=0 , T on entrance=0xffffffffffffffff 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=217 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=65453, isACK=0 1(7698) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 1(7698) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=8173SIPpTag001 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 8f25665e8c867e73b07da3cb1f702171 1(7698) DEBUG: tm [t_funcs.c:324]: t_relay_to(): new INVITE 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) DEBUG: tm [t_reply.c:596]: _reply_light(): reply sent out. buf=0x7fe2c208bea0: SIP/2.0 100 trying -..., shmem=0x7fe2bd0c9f40: SIP/2.0 100 trying - 1(7698) DEBUG: tm [t_reply.c:606]: _reply_light(): finished 1(7698) INFO: <script>: LEL 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_funcs.c:372]: t_relay_to(): new transaction forwarded 1(7698) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 607 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/397) [[SIP/2.0 100 Trying 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb1]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <100> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Trying> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.0>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=2 global id=1 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 0 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=2 global id=2 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[0]=0 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=100 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=-1 icode=0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 118 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/479) [[SIP/2.0 302 Moved Temporarily 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <302> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Moved Temporarily> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.0>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=3 global id=2 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 0 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=3 global id=3 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[0]=100 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=63 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=302 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <302> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Moved Temporarily> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.0>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=63 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2bd0ca850) id=0 global id=0 T start=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7fe2bd0c76d8) already found for msg (0x7fe2bd0ca850)! 1(7698) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <302> 1(7698) INFO: <script>: Call: 302 received, trying to load contacts 1(7698) DEBUG: uac_redirect [rd_funcs.c:72]: get_redirect(): resume branch=0 1(7698) DEBUG: uac_redirect [rd_funcs.c:79]: get_redirect(): checking branch=0 (added=0) 1(7698) DEBUG: uac_redirect [rd_funcs.c:83]: get_redirect(): branch=0 is a redirect (added=0) 1(7698) DEBUG: uac_redirect [rd_funcs.c:159]: sort_contacts(): sort_contacts: <sip:34666988297@10.100.10.67:5060> q=10 1(7698) DEBUG: uac_redirect [rd_funcs.c:295]: shmcontact2dset(): adding contact <sip:34666988297@10.100.10.67:5060> 1(7698) DEBUG: <core> [sruid.c:183]: sruid_next(): new sruid is [rdir-5be42212-1e12-1] (1 / 20) 1(7698) DEBUG: tm [t_serial.c:191]: ki_t_load_contacts(): nr_branches is 1 1(7698) DEBUG: tm [t_serial.c:194]: ki_t_load_contacts(): nothing to do - only one contact! 1(7698) INFO: <script>: LEL 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=-1 icode=0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 581 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/397) [[SIP/2.0 100 Trying 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb1]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <100> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Trying> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.1>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=4 global id=3 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 1 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=4 global id=4 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[1]=0 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=100 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=1, save=0, relay=-1 icode=0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 38 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/482) [[SIP/2.0 503 Service Unavailable 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c86]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <503> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Service Unavailable> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.1>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=5 global id=4 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 1 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=5 global id=5 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[1]=100 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=64 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=503 1(7698) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2bd0cbb88) id=0 global id=0 T start=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7fe2bd0c76d8) already found for msg (0x7fe2bd0cbb88)! 1(7698) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <503> 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2bd0cbb88) id=0 global id=0 T start=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7fe2bd0c76d8) already found for msg (0x7fe2bd0cbb88)! 1(7698) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <503> 1(7698) INFO: <script>: LEL 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=1, save=0, relay=-1 icode=0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 188 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/404) [[SIP/2.0 180 Ringing 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <180> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Ringing> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.2>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=6 global id=5 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 2 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=6 global id=6 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[2]=0 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=180 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=2, save=0, relay=2 icode=0 1(7698) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 404, new size: 318 1(7698) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:112, new: 26, rest: 292 msg= SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-8173-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=8173SIPpTag001 To: "Javi" <sip:34606147628@10.100.10.67:5069>;tag=3 Call-ID: 1-8173(a)10.100.10.67 CSeq: 1 INVITE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Length: 0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 93 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/595) [[SIP/2.0 200 OK 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <200> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <OK> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.2>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=7 global id=6 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 2 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=7 global id=7 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=180, uac[2]=180 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=161 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL v=0 o=user1 53655765 2353687637 IN IP4 10.100.10.67 s=- c=IN IP4 10.100.10.67 t=0 0 m=audio 6000 RTP/AVP 0 18 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=180, new_code=200 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=2, save=0, relay=2 icode=0 1(7698) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 595, new size: 509 1(7698) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:107, new: 21, rest: 488 msg= SIP/2.0 200 OK Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-8173-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=8173SIPpTag001 To: "Javi" <sip:34606147628@10.100.10.67:5069>;tag=3 Call-ID: 1-8173(a)10.100.10.67 CSeq: 1 INVITE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Type: application/sdp Content-Length: 161 v=0 o=user1 53655765 2353687637 IN IP4 10.100.10.67 s=- c=IN IP4 10.100.10.67 t=0 0 m=audio 6000 RTP/AVP 0 18 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 1(7698) DEBUG: tm [t_reply.c:1631]: cleanup_uac_timers(): RETR/FR timers reset 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 185 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/323) [[ACK sip:34606147628@10.100.10.67:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-817]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 1(7698) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <ACK> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5060> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <ACK> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-8173(a)10.100.10.67] - cseq: [1 ACK] 1(7698) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 1(7698) DEBUG: sl [sl_funcs.c:387]: sl_filter_ACK(): too late to be a local ACK! 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=8 , global msg id=7 , T on entrance=0xffffffffffffffff 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=65453, isACK=1 1(7698) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 1(7698) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 1(7698) DEBUG: tm [t_funcs.c:284]: t_relay_to(): forwarding ACK statelessly 1(7698) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 8f25665e8c867e73b07da3cb1f702171 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) DEBUG: <core> [core/forward.c:557]: forward_request(): Sending: ACK sip:34606147628@10.100.10.67:5060 SIP/2.0 Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.0 Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-8173-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=8173SIPpTag001 To: "Test" <sip:34606147628@10.100.10.67:5069>;tag=3 Call-ID: 1-8173(a)10.100.10.67 CSeq: 1 ACK Max-Forwards: 70 Subject: 1 Content-Length: 0 . 1(7698) DEBUG: <core> [core/forward.c:559]: forward_request(): orig. len=323, new_len=414, proto=1 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 109 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/338) [[BYE sip:34606147628@10.100.10.67:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-817]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 1(7698) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <BYE> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5060> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-8>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <2> <BYE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-8173(a)10.100.10.67] - cseq: [2 BYE] 1(7698) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=9 , global msg id=8 , T on entrance=(nil) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=65450, isACK=0 1(7698) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 1(7698) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 1(7698) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 72541dabc2c0991bc1a987a58afe468a 1(7698) INFO: <script>: LEL 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_funcs.c:372]: t_relay_to(): new transaction forwarded 1(7698) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 223 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/396) [[SIP/2.0 200 OK 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKaaff.72541dabc2c0991bc1a987a58afe4]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <200> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <OK> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKaaff.72541dabc2c0991bc1a987a58afe468a.0>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-8>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <2> <BYE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [2 BYE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=10 global id=9 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65450 label 0 branch 0 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0ccd40)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=10 global id=10 T end=0x7fe2bd0ccd40 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=0, uac[0]=0 local=0 is_invite=0) 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=200 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=0 icode=0 1(7698) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 396, new size: 310 1(7698) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:107, new: 21, rest: 289 msg= SIP/2.0 200 OK Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-8173-1-8 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=8173SIPpTag001 To: "Test" <sip:34606147628@10.100.10.67:5069>;tag=3 Call-ID: 1-8173(a)10.100.10.67 CSeq: 2 BYE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Length: 0 1(7698) DEBUG: tm [t_reply.c:1631]: cleanup_uac_timers(): RETR/FR timers reset 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 74 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 3(7700) DEBUG: tm [h_table.c:129]: free_cell_helper(): freeing transaction 0x7fe2bd0c76d8 from timer.c:654 3(7700) DEBUG: tm [h_table.c:129]: free_cell_helper(): freeing transaction 0x7fe2bd0ccd40 from timer.c:654

3 5

dlflags interface deprecated
by AL S 13 Nov '18

13 Nov '18

Hi, We are running the old release of Kamailio 3.3.7 and getting the following notice log: kamailio: NOTICE: <core> [sr_module.c:627]: /usr/local/lib64/kamailio/modules_k/perl.so: exports dlflags interface is deprecated and it will not be supported in newer versions; consider using mod_register() instead Is there a way to fix this issue on the same Kamailio3.3.7 code? Thanks, AL

3 2

Execution Sequence of the Request_Route
by Abdulaziz Alghosh 13 Nov '18

13 Nov '18

Hello, I migrated from Kamailio 3.0.3 to Kamailio 5.1.4. and have two questions about the execution sequence of the Request_Route. The following condition trys to authenticate the first INVITE or REGISTER request which normally does not have the Authorization Header: route (auth) .. .. .. route[auth]{ if ( !proxy_authorize("myrealm", "subscriber") ) { proxy_challenge("myrealm", "0"); sl_reply_error(); exit; }; return; } For sure the Return Code of "proxy_authorize" will not be one (1) at the beginneing, so the proxy_challenge() will generate the "407 Proxy Authentication Required" request and the agent will send the INVITE or the REGISTER again with the Authorization-Header and the call or the registration attempt succeeds. During my observation to the new returned codes (values) of both proxy_authorize() and proxy_challenge() in Kamailio 5.1.4, I noticed the following differnet execution sequence of this "Request_Route". at Kamailio 3.0.3, and exactly after the proxy_challenge("myrealm", "0") command was executed, no more commands were excuted as if it jumped out of the if statement, and the proxy was wating for the new INVITE or REGISTER. Hence the sl_reply_error() did not send any error reply. I wrote several logging commad before and after the proxy_challenge("myrealm", "0"), so I am pretty sure that the proxy_challenge("myrealm", "0") is last excuted command to be excuted here. at Kamailio 5.1.4, the behaviour was more logical and the proxy executes commands which come under the proxy_challenge("myrealm", "0") like logging commands or sl_reply_error() which generates usually the error reply " 500 I'm terribly sorry, server error occurred". My first question is: May somebody explain this different behavior? My second Question: assume that the agent will send a wrong credentials and response, does the proxy_challenge("myrealm", "0") function terminate this dialouge with 401 Unauthorized Error or I must add the following "if condition" afterwards: if ( !proxy_authorize("myrealm", "subscriber") ) { proxy_challenge("myrealm", "0"); if (!$rc){ sl_reply_error(); '#### or I will be more specific sl_send_reply (code, reason) } exit; }; Thanks and best regards Abdulaziz Alghosh

2 1

Redirects - are q values required to implement serial forking?
by Mike Montgomery 12 Nov '18

12 Nov '18

We have a situation where we get a redirect from a carrier with a list of carriers to send the transaction to in the contact header. None of the carriers in the contact header have q values assigned. We have implemented our redirect handling logic using the UAC_REDIRECT module (get_redirects()) with help from TM module (t-load_contacts(), t_next_contact()). (failure_route code is at bottom of this note) We find that when we receive a contact header with q values, we can launch requests serially using t_next_contact() and individually work through the contact list until we get a positive response. When we get a redirect with no q values in the contact header we find that all contacts get loaded and launched in parallel. Although not stated in the documentation, it appears that in order to implement serial contact redirect handling, q values must be present in the contact header. Based on this assumption, and knowing that the redirecting carrier cannot include q values, we have attempted to modify the contact header and find that we are unable to add q values to the contact header. We have attempted without success to use remove_hf("Contact”) followed by append_hf("Contact: $(avp(contact)) \r\n”); where $(avp(contact)) is the avp where we have rewritten the contact header to include q values. Any guidance on how to handle this issue is appreciated. _________________________________________________________- Our failure route code: if (t_check_status("3[0-9][0-9]")) { xlog("L_INFO", "----> REDIRECT Contact Header --> $T_rpl($ct) --- Method $rm --- From $T_req($fu) --- To $T_req($tu) --- Destination $T_req($du) \n"); get_redirects("*:*"); if (!t_load_contacts()) { xlog("L_INFO", "-t_load_contacts() FAILED /n"); }; xlog("L_INFO", "####->LOAD CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); if (t_next_contacts()) { xlog("L_INFO", "-t_next_contact() loaded successfully /n"); xlog("L_INFO", "####-> NEXT CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); }; t_on_failure("serial"); if(t_relay()){ xlog("L_INFO","----->Relayed in MANAGE_FAILURE --- Method $rm --- Contact Header $ct \n"); }; exit; } else { xlog("L_INFO","-----> NO REDIRECT --- Method $rm --- Contact Header $ct \n"); exit; } failure_route["serial"] { xlog ("L_INFO", "Entered failure_route(serial) /n"); if (t_check_status("3[0-9][0-9]")) { xlog("L_INFO", "----> DOUBLE REDIRECT Contact Header --> $T_rpl($ct) --- Method $rm --- From $T_req($fu) --- To $T_req($tu) --- Destination $T_req($du) \n"); $xavp(tm_contacts[*]) = $null; xlog("L_INFO", "XXX-> tm_contacts reset to Null $xavp(tm_contacts[0]=>uri)\n"); get_redirects("*:*"); if (!t_load_contacts()) { xlog("L_INFO", "-t_load_contacts() FAILED /n"); }; xlog("L_INFO", "####-> LOAD 2 CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); } if (!t_next_contacts()) { exit; } xlog("L_INFO", "-t_next_contact() loaded successfully /n"); xlog("L_INFO", "####-> NEXT CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); t_on_failure("serial"); if(t_relay()){ xlog("L_INFO","----->Relayed in failure_route(serial) --- Method $rm --- Contact Header $ct \n"); }; } Best Regards, Mike Montgomery Principal, Trusted Technical Services, Inc. o - 919 924 4703 x3000 m - 919 539 6133

2 1

Adding Perl Module to kamailio-5.1.6
by AL S 12 Nov '18

12 Nov '18

I am trying to install Perl module on Ubuntu 18.04 / Kamailio kamailio-5.1.6 and getting the following response: $ sudo apt-get install kamailio-perl-modules Reading package lists... Done Building dependency tree Reading state information... Done kamailio-perl-modules is already the newest version (5.1.2-1ubuntu2). You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: kamailio-perl-modules : Depends: kamailio (= 5.1.2-1ubuntu2) but it is not installable E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Is there a better way to add perl module? PS: libperl-dev already installed. Thanks, AL

2 1

siptrace module doesn't close db connections
by Roman Dissauer 12 Nov '18

12 Nov '18

Hi, it seems that siptrace module doesn’t close db connections. I’m on Kamailio 5.1.4 from official debian stretch repository with postgresql db module enabled. siptrace config: modparam("siptrace", "db_url", DBURL) modparam("siptrace", "duplicate_uri", "sip:193.32.51.189:9060") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "hep_capture_id", 1001) modparam("siptrace", "trace_mode", 1) Here you can see the open connections from the kamailio host: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.101.61'; client_addr | state | query --------------+-------+---------------------------------------------------------------- 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' (31 Zeilen) another example, other installation with same kamailio version 5.1.4: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.102.1'; client_addr | state | query -------------+-------+---------------------------------------------------------------- 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' (39 Zeilen) Thanks Roman

2 2

Single session start
by José Antonio Gutiérrez Delgado 12 Nov '18

12 Nov '18

Hi, I would like to know if it is possible to make the last register of a user the active register and if possible the only one. I'm with an Android application and sometimes I can not deregister properly before the new registration, for example when the network changes, so there are times when the hanging signals do not work correctly when there is more than one register for a user. Is it possible to avoid that there is more than one register for a user? Is it possible to configure the last register to delete the previous ones or to be a single register? Thanks in advance and I await your answers. -- José Antonio Gutiérrez Delgado Responsable técnico Oficina: (+34) 923040031 <http://www.arsoft-company.com/> *Este mensaje se dirige exclusivamente a su destinatario/s y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.* *Antes de imprimir, piensa si es necesario. Cuidar el medioambiente es tarea de todos.*

3 2

Custom authentication
by João Sávio 12 Nov '18

12 Nov '18

Hello! I was reading the documentation of Kamailio, And, although there are some authentication modules, I couldn't find a way to implement a custom authentication for SIP Register. Something that allows me, for example, to call a web server and returns if the user is authenticated, or the user data. Am I missing anything? Do you know if it's possible to do this using another way? Thanks João

2 2

high availability and load balancing
by eyas barhouk 10 Nov '18

10 Nov '18

hello dears, i'm using kamailio 5.1 as IMS , and i have the following servers: * p-cscf * i-cscf-1 ,icscf-2 * s-cscf-1,scscf-2 i need to do high availability and load balancing between my servers , but i have some questions like do i have to use keepalived or dispatcher module and what the benefits of each one of them ,and on load balancing method should i do it for the register requests or only for invite requests or just for every thing ?? if any one has an idea or any thing to guide me i will be thankful thanks in advance and regards

3 3

Client Registration and Call over Kamailio
by serkan celik 09 Nov '18

09 Nov '18

Hi all, I am using Kamailio as a proxy in front of a 3rd part Open IMS (Not IMS modules in kamailio). I have defined Kamailio as an outbound proxy in Soft clients(I have configured IMS users info in Soft Clients). When I send register from client to IMS, Register message is sent to IMS over Kamailio. Kamailio forwards this received Register to the 3rd party IMS. Finally the client is registered into IMS over Kamailio. However when I try to make a call from registered users (both registered over Kamailio), IMS sends 403 Forbidden - "Not Registered! You must register first with a S-CSCF" to Kamailio. When I debugged the issue I found the reason why IMS sends 403. When IMS receives an Invite message from Kamailio it checks whether source IP which Invite is sent registered or not. As I make registration over Kamailio without changing contact header, IMS registers the user with the contact IP (which is the client IP). So to make a call from Soft client (IMS users) over Kamailio I also need to register Kamailio source IP as well.To deal with the issue I have changed the contact address of Register message coming from Soft client with Kamailio IP on Kamailio. Then IMS registered Kamailio IP as a contact when registering IMS user. But this time when I make a call from Soft client over Kamailio, IMS sends Termination Invite to Kamailio. So to finalize the call Kamailio has to route this termination Invite to the terminating IMS user . Is there any better approach to overcome this issue. Which is the better approach to use Kamailio in front of IMS. I want to both register and make a call from Soft clients over Kamailio to the IMS. Regards, Serkan CELIK

3 5

systemd kamailio.service - RFC Wants=network-online.target
by Kevin Olbrich 08 Nov '18

08 Nov '18

Hi! The systemd kamailio.service file for debian (in my case, it's stretch) has the following unit options set: [Unit] > Description=Kamailio (OpenSER) - the Open Source SIP Server > After=network.target It would be better to change this to: [Unit] > Description=Kamailio (OpenSER) - the Open Source SIP Server > Wants=network-online.target > After=network-online.target Why? With network.target the service starts as soon as the network setup is started, not explicitly after configuring (=IP) it [1]. This creates a race condition on very fast hardware like mine (booting incl. all services takes 10s). Even with static IPs, kamailio often fails directly at boot because eth1 (connection to DB cluster) is not up. [I have never met this problem on systems which ran on HDDs.] Setting "network-online.target" as Wants + After makes sure, Kamailio is started after all interfaces are ready to serve. Units that strictly require a configured network connection should pull in > network-online.target (via a Wants= type dependency) and order themselves > after it. This target unit is intended to pull in a service that delays > further execution until the network is sufficiently set up. What precisely > this requires is left to the implementation of the network managing service. > Perfect example for this is the Shorewall package (firewall solution): [Unit] > Description=Shorewall IPv4 firewall > Wants=network-online.target > After=network-online.target > Conflicts=iptables.service firewalld.service RFC Kind regards Kevin [1] https://www.freedesktop.org/software/systemd/man/systemd.special.html

3 6

cfg_lock_helper(): lock set not initialized
by Kjeld Flarup 08 Nov '18

08 Nov '18

Hi What does this error actually mean? I get it with 5.1.4 Nov 6 13:27:02 scantronpbx /usr/sbin/kamailio[2149]: ERROR: cfgutils [cfgutils.c:708]: cfg_lock_helper(): lock set not initialized (attempt to do op: 1 on: u1) -- -------------------- Med Liberalistiske Hilsner ---------------------- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

2 1

Phone does not set "Expire-header" but "Contact expire", immediately expires
by Kevin Olbrich 07 Nov '18

07 Nov '18

Hi! I have a phone (Mitel 6930) that does not send an Expire-header but "expire" in Contact during REGISTER: Session Initiation Protocol (REGISTER) > Request-Line: REGISTER sip:pbx.example.com SIP/2.0 > Message Header > Via: SIP/2.0/TLS 192.168.6.16:5061;branch=xxxxxxxxxxxxxxxx;rport > Route: <sip:pbx.example.com;lr=lr;transport=tls> > Max-Forwards: 70 > From: "Example" <sip:121212_6666@pbx.example.com>;tag=b0cec92c3e > To: "Example" <sip:121212_6666@pbx.example.com> > Call-ID: aaaaaaaaaaaaaaaaa > CSeq: 1190442896 REGISTER > Accept-Language: de > Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, > PRACK, SUBSCRIBE, INFO, PUBLISH > Allow-Events: talk, hold, conference, LocalModeStatus > Contact: "Example" <sip:121212_6666@192.0.2.1:62336 > >;+sip.instance="<urn:uuid:00000000-0000-1000-8000-08000FB888F5>";expires=300 > Supported: path, gruu > User-Agent: Mitel 6930/5.0.0.2041 > Aastra-Line: 1 > Aastra-Mac: AAAAAAAAAAAA > Content-Length: 0 This results in successful register, kamailio forwards REGISTER to asterisk (endpoint registered) and immediatly kamailio sends a new REGISTER with Expire set to 0 to asterisk: Session Initiation Protocol (REGISTER) > Request-Line: REGISTER sip:192.168.99.112:5060 SIP/2.0 > Message Header > Via: SIP/2.0/UDP 192.168.99.111:5060 > ;branch=z9hG4bK9f9e.599cf243000000000000000000000000.0 > To: <sip:121212_6666@192.168.99.112> > From: <sip:121212_6666@192.168.99.112 > >;tag=7e4f6993bfbf831f6b016fea6683cdca-b98a > CSeq: 10 REGISTER > Call-ID: 2bc5fd1061b31723-1350(a)192.168.99.111 > Max-Forwards: 70 > Content-Length: 0 > User-Agent: kamailio (5.1.6 (x86_64/linux)) > Contact: <sip:121212_6666@192.168.99.111:5060> > Expires: 0 The phone is then unregistered - the phone also shows "no service". It looks like Kamailio generates this message on it's own (and I don't know why). I am still learning to implement kamailio as proxy. Reading the docs, I would expect Kamailio to automatically eval the correct parameter: > If the processed message contains neither Expires HFs nor expires contact > parameters, this value will be used for newly created usrloc records. [1] What did I miss? Phones which use the Expire-header are working fine. Kind regards Kevin [1] default_expires - http://www.kamailio.org/docs/modules/5.2.x/modules/registrar.html

3 10

busy lamp field
by Kevin Olbrich 06 Nov '18

06 Nov '18

Hi! Can someone share his kamailio.cfg with working busy lamp field in a kamailio-as-proxy scenario? My config is based on the example shipped with 5.1.x and asterisk as the backend. Calling works fine but PUBLISH / SUBSCRIBE is handled by kamailio itself. I am not sure but this might be the part where I should relay the request to asterisk(?): #!ifdef WITH_PRESENCE > if (!t_newtran()) { > sl_reply_error(); > exit; > } > if(is_method("PUBLISH")) { > handle_publish(); > t_release(); > } else if(is_method("SUBSCRIBE")) { > handle_subscribe(); > t_release(); > } > exit; > #!endif Currently the lights are "broken", some phones show them on, some off. Kind regards Kevin

2 1

Kamailio SQL error
by Marcos Pytel 06 Nov '18

06 Nov '18

Hello team! Im using kamailio in sipwise! I get this errors: Nov 5 11:51:34 sipwise proxy[1943]: ERROR: <core> [db_query.c:235]: db_do_insert_cmd(): error while submitting query Nov 5 11:51:34 sipwise proxy[1943]: ERROR: presence [subscribe.c:2514]: update_db_subs_timer(): unsuccessful sql insert Nov 5 11:51:34 sipwise proxy[1943]: ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Duplicate entry '6c23f96-0001-0003-0030(a)10.7.255.250-f3067022b00c564156251ba2f28f' for key 'active_watchers_idx' (1062) How can I fix it? Thank you! Marcos.

2 2

db_mongodb_get_columns(): field [username] not found in result iterator
by Denys Pozniak 06 Nov '18

06 Nov '18

Hello! I want to keep user location in mongodb, but Kamailio does not start well. Configuration: loadmodule "usrloc.so" loadmodule "db_mongodb.so" modparam("usrloc", "db_insert_null", 1) modparam("usrloc", "db_url", "mongodb://mongodb.test/kamailio") modparam("usrloc", "db_mode", 2) modparam("usrloc", "timer_interval", 30) modparam("usrloc", "desc_time_order", 1) Mongodb: rs0:PRIMARY> use kamailio switched to db kamailio rs0:PRIMARY> db.location.find() { "_id" : ObjectId("5be024d6b9d8febf4ae19681"), "name" : "location", "version" : 9, "columns" : { "id" : { "type" : "int", "default" : null, "null" : false }, "ruid" : { "type" : "string", "default" : "", "null" : false }, "username" : { "type" : "string", "default" : "", "null" : false }, "domain" : { "type" : "string", "default" : null, "null" : true }, "contact" : { "type" : "string", "default" : "", "null" : false }, "received" : { "type" : "string", "default" : null, "null" : true }, "path" : { "type" : "string", "default" : null, "null" : true }, "expires" : { "type" : "datetime", "default" : "2030-05-28 21:32:15", "null" : false }, "q" : { "type" : "double", "default" : 1, "null" : false }, "callid" : { "type" : "string", "default" : "Default-Call-ID", "null" : false }, "cseq" : { "type" : "int", "default" : 1, "null" : false }, "last_modified" : { "type" : "datetime", "default" : "2000-01-01 00:00:01", "null" : false }, "flags" : { "type" : "int", "default" : 0, "null" : false }, "cflags" : { "type" : "int", "default" : 0, "null" : false }, "user_agent" : { "type" : "string", "default" : "", "null" : false }, "socket" : { "type" : "string", "default" : null, "null" : true }, "methods" : { "type" : "int", "default" : null, "null" : true }, "instance" : { "type" : "string", "default" : null, "null" : true }, "reg_id" : { "type" : "int", "default" : 0, "null" : false }, "server_id" : { "type" : "int", "default" : 0, "null" : false }, "connection_id" : { "type" : "int", "default" : 0, "null" : false }, "keepalive" : { "type" : "int", "default" : 0, "null" : false }, "partition" : { "type" : "int", "default" : 0, "null" : false } } } { "_id" : ObjectId("5be02a77175610be86a1a589"), "username" : "dummy_user" } Syslog: Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: db_mongodb [mongodb_dbase.c:416]: db_mongodb_get_columns(): field [username] not found in result iterator Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: db_mongodb [mongodb_dbase.c:815]: db_mongodb_store_result(): failed to set the columns Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: db_mongodb [mongodb_dbase.c:1018]: db_mongodb_query(): failed to store result Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: db_mongodb [mongodb_dbase.c:1027]: db_mongodb_query(): failed to do the query Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: usrloc [udomain.c:457]: preload_udomain(): db_query failed Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: usrloc [usrloc_mod.c:430]: child_init(): child(1): failed to preload domain 'location' Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: <core> [core/sr_module.c:946]: init_mod_child(): error while initializing module usrloc (/usr/lib64/kamailio/modules/usrloc.so) (idx: 1 rank: 1 desc: [udp receiver child=0 sock=10.10.10.10:5060]) Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: <core> [core/pt.c:340]: fork_process(): init_child failed for process 1, pid 21543, "udp receiver child=0 sock=10.10.10.10:5060" Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: CRITICAL: <core> [main.c:1607]: main_loop(): Cannot fork 2018-11-05T13:07:19.117+0100 D COMMAND [conn367] run command kamailio.$cmd { find: "version", filter: { table_name: "location" }, projection: { table_version: 1 } } 2018-11-05T13:07:19.118+0100 I COMMAND [conn367] command kamailio.version command: find { find: "version", filter: { table_name: "location" }, projection: { table_version: 1 } } planSummary: COLLSCAN keysExamined:0 docsExamined:2 cursorExhausted:1 numYields:0 nreturned:1 reslen:148 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 0ms 2018-11-05T13:07:19.118+0100 D COMMAND [conn367] run command kamailio.$cmd { find: "location", filter: { username: "dummy_user" }, projection: { username: 1 } } 2018-11-05T13:07:19.119+0100 I COMMAND [conn367] command kamailio.location command: find { find: "location", filter: { username: "dummy_user" }, projection: { username: 1 } } planSummary: COLLSCAN keysExamined:0 docsExamined:2 cursorExhausted:1 numYields:0 nreturned:1 reslen:155 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 0ms 2018-11-05T13:07:19.178+0100 D COMMAND [conn368] run command kamailio.$cmd { find: "location", filter: {}, projection: { username: 1, contact: 1, expires: 1, q: 1, callid: 1, cseq: 1, flags: 1, cflags: 1, user_agent: 1, received: 1, path: 1, socket: 1, methods: 1, last_modified: 1, ruid: 1, instance: 1, reg_id: 1, server_id: 1, connection_id: 1, keepalive: 1 } } 2018-11-05T13:07:19.179+0100 I COMMAND [conn368] command kamailio.location command: find { find: "location", filter: {}, projection: { username: 1, contact: 1, expires: 1, q: 1, callid: 1, cseq: 1, flags: 1, cflags: 1, user_agent: 1, received: 1, path: 1, socket: 1, methods: 1, last_modified: 1, ruid: 1, instance: 1, reg_id: 1, server_id: 1, connection_id: 1, keepalive: 1 } } planSummary: COLLSCAN keysExamined:0 docsExamined:2 cursorExhausted:1 numYields:0 nreturned:2 reslen:180 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 0ms [root@dev-rtpengine kamailio]# kamailio -v version: kamailio 5.1.6 (x86_64/linux) 7d1964 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 7d1964 compiled on 11:10:15 Nov 4 2018 with gcc 4.8.5 -- BR, Denys Pozniak

2 5

Fwd: Fw: kamailio5.0.0 support presence
by chaos wu 06 Nov '18

06 Nov '18

Hi Kamailio expert, i want to use kamailio to simulate presence server, after receive subscribe, i need kamailio reply 200 OK, and then send out Notify, but now, it just forward the subscribe, don't reply, could you help check my cfg? thanks in advance. BRs

2 1

Development is open for future release v5.3.x series
by Daniel-Constantin Mierla 06 Nov '18

06 Nov '18

Hello, with the creation of branch 5.2 done this morning, the master branch is from now on open for adding new features, to be part of future release series v5.3.x. Any bug fix committed to master that applies to 5.2.x or older stable branches should be backported as usual with git cherry-pick to appropriate branches like 5.2 or 5.1. Expect that v5.2.0 will be released in about 2-3 weeks from now. Based on the workflow used during the past years, the next future release v5.3.0 should be out after another 8-10 months of development, plus 1-2 months of testing, so sometime in the summer or autumn of 2019. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

1 0

Branch 5.2 has been created
by Daniel-Constantin Mierla 06 Nov '18

06 Nov '18

Hello, the branch 5.2 has been created, to be used for releasing v5.2.x series. To check out this branch, the following commands can be used: git clone https://github.com/kamailio/kamailio kamailio-5.2 cd kamailio-5.2 git checkout -b 5.2 origin/5.2 Pushing commits in this branch: git push origin 5.2:5.2 Note that 5.2 is an official stable branch, so only bug fixes, missing kemi exports (discuss on sr-dev if not sure) or improvements to documentation or helper tools can be pushed to this branch. As usual, if there is a bug fixed, commit and push first to master branch and then cherry pick to 5.2 branch. In few weeks, the first release from branch 5.2 will be out, respectively Kamailio v5.2.0. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

1 0

Use of SCTP on public SIP server
by Kevin Olbrich 06 Nov '18

06 Nov '18

Hi! I read about the SCTP module for Kamailio and I am not sure if I should load it (currently I am not). Does this provide any benefit when Kamailio is used as proxy in front of Asterisk? At least from Wikipedia and the kamailio docs, it sounds like I can load it and it does it's magic. The multihomed part caught my attention. Kinds regards Kevin

3 2

How register with STORE_PLAINTEXT_PW=0
by José Antonio Gutiérrez Delgado 05 Nov '18

05 Nov '18

Hello, I recently discovered that the Kamailio database stores the user's password directly. I have found that by changing STORE_PLAINTEXT_PW = 0 in the configuration file, it stops storing the password in the database, but if I make this change I can no longer register the users in Kamailio. How should I register if I do not store the password? Have I missed a step? I have read that it is related to the HA1 field but it has not been clear how to do it. I hope your help. Thank you. -- José Antonio Gutiérrez Delgado Responsable técnico Oficina: (+34) 923040031 <http://www.arsoft-company.com/> *Este mensaje se dirige exclusivamente a su destinatario/s y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.* *Antes de imprimir, piensa si es necesario. Cuidar el medioambiente es tarea de todos.*

2 2

Storing in-progress dialogs in database
by jenus＠cyberchaos.nl 05 Nov '18

05 Nov '18

Hi all, I'm testing with the new dlg_db_load_callid function to replicate dialogs to another (standby) kamailio instance on failover. This works fine for calls that are connected. But i'm missing the dialogs in "ringing" state. Looks like dialogs are written to database by the dialog module when we receive the 200OK/ACK for the invite transaction. The result is that the call gets connected on the other kamailio instance but without a dialog. Is it possible to store the early_dialogs that are in rining state in the database? If that is not the case can i still create a dialog when i only receive the 200OK/ACK to the INVITE transaction (INVITE was processed by another instance) since TM is not aware of the INVITE transaction? I also tried to reject the 200OK to the INVITE in the on reply route, but running into the same issue that TM does not know the INVITE transaction. Thanks, Jan

2 1

string in ims_diameter_server
by Iman Mohammadi 04 Nov '18

04 Nov '18

We have a problem putting data to an AVP object. The data type is byte array (:byte[]). If we convert that array to an integer and put it in 'int32' field then the module just gets the first 4 bytes. If we convert it to base64 or hexString and put it in 'string' field then it treats it as a regular string. And any other field beside 'int32' and 'string' will be ignored. So the question is, how we put a byte array inside an AVP and send it to the module so the diameter gets the data as a byte array? Best Regards Iman Mohammadi

1 0

Branching GIT repository for 5.2.x release series
by Daniel-Constantin Mierla 03 Nov '18

03 Nov '18

Hello, if there is no other opinion, I am considering to create git branch 5.2 at the beginning of next week (likely on Monday evening), to be used for 5.2.x release series. >From that moment, the master branch can get new features and the appropriate bug fixes have to be backported to branch 5.2 as well. With this step, the first release in 5.2.x series, respectively v5.2.0, should be out in about 2-3 weeks. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

2 1

Crash ims_diameter_server
by Iman Mohammadi 03 Nov '18

03 Nov '18

When the below format is sent from rest , kamailio crashes List[{ List[{ List[{ ]} ]} ]} (Json with 3 nested lists), With 2 lists it works properly, When diameter is translated to json with 3 lists by this module it also works properly, Json format is correct too. gdb: gdb) bt full #0 0x00007f5e23c4a11e in diameterserver_add_avp (m=0x0, d=0x7f5e1b5c2240 "", len=12, avp_code=431, flags=64, vendorid=0, data_do=2, func=0x7f5e23c51d6c <__FUNCTION__.20148> "parselist") at avp_helper.c:208 avp = 0x7f5e1b5c3bd0 __FUNCTION__ = "diameterserver_add_avp" #1 0x00007f5e23c4d0c8 in parselist (response=0x0, list=0x7fff9f21a8d0, item=0x11b67d0, level=2) at avp_helper.c:309 i = 1 flags = 64 x = "p\250!\237" avp_list = {head = 0x0, tail = 0x0} avp_list_s = {s = 0x7f5e1b5c2240 "", len = 12} __FUNCTION__ = "parselist" #2 0x00007f5e23c4cffc in parselist (response=0x7f5e1b5c3ab8, list=0x0, item=0x11b6550, level=1) at avp_helper.c:304 subitem = 0x11b67d0 i = 0 flags = 64 x = "\000\000\000" avp_list = {head = 0x0, tail = 0x0} avp_list_s = {s = 0x7fff9f21a8f0 "@\251!\237\377\177", len = 600070897} __FUNCTION__ = "parselist" #3 0x00007f5e23c4db3a in addAVPsfromJSON (response=0x7f5e1b5c3ab8, json=0x7f5e23e53950 <responsejson>) at avp_helper.c:349 subitem = 0x11b6550 i = 4 __FUNCTION__ = "addAVPsfromJSON" root = 0x11b4210 #4 0x00007f5e23c3fbdb in callback_cdp_request (request_in=0x7f5e1b5c19b0, param=0x0) at ims_diameter_server.c:193 fmsg = 0xab7840 <_faked_msg> backup_rt = 1 ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = {{__jmpbuf = {1, -5713032302318786866, 7971288, 7971288, 140042162528420, 0, -5713032302339758386, 5712822384154044110}, __mask_was_saved = 0, __saved_mask = {__val = { 140735863172072, 127, 0, 140042162532340, 140042389578761, 4222451713, 140042162532340, 140042162532340, 140042162532340, 140042162532340, 140042162532358, 140042162532467, 140042162532340, 140042162532467, 0, 0}}}}} response = 0x7f5e1b5c3ab8 __FUNCTION__ = "callback_cdp_request" #5 0x00007f5e24a705c0 in api_callback (p=0x7f5e1b598f50, msg=0x7f5e1b5c19b0, ptr=0x0) at api_process.c:83 t = 0x7f5e1b598f50 auto_drop = 32767 h = 0x7f5e1b5b3358 ---Type <return> to continue, or q <return> to quit--- x = {type = (unknown: 2669784000), handler = {requestHandler = 0x7f5e23c3eed1 <callback_cdp_request>, responseHandler = 0x7f5e23c3eed1 <callback_cdp_request>}, param = 0x3ee9f21ac10, next = 0x7f5e1b5988b8, prev = 0x19f210069} type = REQUEST_HANDLER rsp = 0x7f5e1b5c19b0 __FUNCTION__ = "api_callback" #6 0x00007f5e24a857d7 in worker_process (id=5) at worker.c:346 t = {p = 0x7f5e1b598f50, msg = 0x7f5e1b5c19b0} cb = 0x7f5e1b59df30 r = 128 __FUNCTION__ = "worker_process" #7 0x00007f5e24a62a8e in diameter_peer_start (blocking=0) at diameter_peer.c:242 pid = 0 k = 5 p = 0x36 __FUNCTION__ = "diameter_peer_start" #8 0x00007f5e24a559bc in cdp_child_init (rank=0) at cdp_mod.c:243 __FUNCTION__ = "cdp_child_init" #9 0x0000000000547e54 in init_mod_child (m=0x7f5e28656fb8, rank=0) at core/sr_module.c:943 __FUNCTION__ = "init_mod_child" #10 0x0000000000547b16 in init_mod_child (m=0x7f5e28657c38, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #11 0x0000000000547b16 in init_mod_child (m=0x7f5e28658010, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #12 0x0000000000547b16 in init_mod_child (m=0x7f5e28658790, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #13 0x0000000000547b16 in init_mod_child (m=0x7f5e28658d68, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #14 0x00000000005481e6 in init_child (rank=0) at core/sr_module.c:970 No locals. #15 0x00000000004250f5 in main_loop () at main.c:1701 i = 8 pid = 1964 si = 0x0 si_desc = "udp receiver child=7 sock=10.25.5.23:5060\000y\000\000\000\000\000x\333i(^\177\000\000@\264!\237\377\177", '\000' <repeats 18 times>, "`\263!\237\377\177\000\000\347L\340(^\177\000\000\360\260!\237\377\177\000\000\060\000\000\000\060\000\000\000\260\261!\237\377\177\000\000\350\226i(^\177\000" nrprocs = 8 ---Type <return> to continue, or q <return> to quit--- woneinit = 1 __FUNCTION__ = "main_loop" #16 0x000000000042b99b in main (argc=13, argv=0x7fff9f21b448) at main.c:2638 cfg_stream = 0x111c020 c = -1 r = 0 tmp = 0x7fff9f21bf69 "" tmp_len = 32606 port = 693647725 proto = 0 options = 0x74cd90 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 898203166 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x7fff9f21b300 p = 0x7fff9f21b4b8 "\207\277!\237\377\177" st = {st_dev = 15, st_ino = 13240, st_nlink = 2, st_mode = 16877, st_uid = 110, st_gid = 116, __pad0 = 0, st_rdev = 0, st_size = 60, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1540797448, tv_nsec = 544589798}, st_mtim = {tv_sec = 1540797905, tv_nsec = 662909589}, st_ctim = {tv_sec = 1540798045, tv_nsec = 563947001}, __glibc_reserved = {0, 0, 0}} __FUNCTION__ = "main" (gdb) (gdb) Where is problem? Thanks

3 4

Store TLS handshake date from Kamailio to an external DB
by Toffi Bossol 02 Nov '18

02 Nov '18

Dear community, I am new in Kamailio hence the following question: Does any one know how to tell Kamailio to store the TLS session data in an external DB? Many Thanks in advance! BR; Toffi

3 7

Installing rtpengine from RPM on CentOS
by Pan Christensen 02 Nov '18

02 Nov '18

Hello! According to https://github.com/sipwise/rtpengine/blob/master/el/README.el.md , we should be able to install rtpengine from a CentOS repository using yum. We're unable to find the packages. Any suggestions? Pan B. Christensen Developer Phonect AS Mail: pan.christensen(a)phonect.no<mailto:pan.christensen@phonect.no> + 47 41 88 88 00 [mail_footer]

5 5

Parse Header error when send Register to P-CSCF using ims-pcscf
by Hưng Nguyễn Tiến 02 Nov '18

02 Nov '18

Hi, i'm newbie in kamailio, I tried installed ims kamailio from ng-repository packages, Then when I tried to send register to SIP server using SIPp, I received this log [Proxy-CSCF][28505]: ERROR: <core> [core/parser/msg_parser.c:331]: parse_headers(): bad header field [(null)] [Proxy-CSCF][28500]: ERROR: <core> [core/parser/msg_parser.c:331]: parse_headers(): bad header field [(null)] [Proxy-CSCF][28496]: WARNING: <core> [core/receive.c:192]: receive_msg(): parsing relevant headers failed [Proxy-CSCF][28505]: message repeated 2 times: [ WARNING: <core> [core/receive.c:192]: receive_msg(): parsing relevant headers failed] [Proxy-CSCF][28492]: ERROR: <core> [core/parser/msg_parser.c:675]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023�#023��z'��z'#006��[%�#007> Thank you -- Nguyễn Tiến Hưng

2 1

Diversion headers access and message too long error
by Joan Salvatella 01 Nov '18

01 Nov '18

Hello, We are working on a project that's using a Twilio SIP trunk that diverts calls from the PSTN to our cluster that is hosting two active-active Kamailio 5.1 instances that redirect traffic to several Asterisk 15.4 instances. On this setup we are facing 2 issues: - *Diversion headers access: *Currently, Kamailio only supports access to the last diversion header but since we are receiving traffic from Twilio (it sets the last Diversion header) we are unable to see if the caller was diverted to our SIP trunk. Is there a workaround for this? Any external module that would support this use case? - *Message Too Long Error:* Since Twilio uses long URIs to define its resources, the SIP messages being handled by Kamailio are sometimes too big and generate a "Message Too Long error". I have been able to temporarily patch this removing unused headers using remove_hf_re and remove_hf but it still fails from time to time. Is there a way to split the UDP packet to mitigate this issue? or what other options could be considered? Thanks and regards,

3 5

[CentOS 7] Kamailio 5.1.x mongodb package missing in OpenSUSE repo.
by Denys Pozniak 01 Nov '18

01 Nov '18

Hello! How can I add module DB_MONGODB to existing installation of Kamailio 5.1.6 , if there is no package in OpenSUSE repo (home:kamailio:v5.1.x-rpms.repo) ? -- BR, Denys Pozniak

2 1

Topos on high load
by Igor Olhovskiy 01 Nov '18

01 Nov '18

Hi! We’ve run into really interesting issue while testing Kamailio with sipp (15 CPS, 300 calls - 1 failed call, more CPS - more failed calls) with topos involved. And at some point Kamailio starts to send 2 packets on received INVITE. 1 - with topos applied, 1 - with not. Main problem is to collect logs at this point, cause load is really high. Is it possible some internal race condition while topos involved? PCAP is attached. I’ve made a picture to illustrate a bit an issue Regards, Igor

2 2

Determine destination address family
by Isaac 31 Oct '18

31 Oct '18

Hello, How can I determine the address family (IPv6 or IPv4) of a destination? The destination in this case is a hostname. I'd like to set a flag if the destination is IPv6 but not sure how to go about it. Thanks, Isaac

2 2

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