As I could notice upon a quick look, there seems to be two calls -- two INVITE requests having same call id but different cseq. Can you confirm this is the case? Because the capture doesn't seem to have all the incoming/outgoing messages, some are missing. Cheers, Daniel On 26.04.17 12:59, Sergey Basov wrote: present. specify be wrote: hide work wrote: pushed to pkelly(a)gmail.com> the the pkelly(a)gmail.com> There yes nightly build. 192.168.252.70 are 2 networks. frame 35 missing all causes the ACK to related to Kamailio. (i.e. the network). realising the ACK directly mailing (USA) - www.kamailioworld.com www.kamailioworld.com -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

Can you paste here the from tag or cseq for the dialog you are referring to? Because the number of frames are not matching my pcap viewer. Send also the db dump, they should reveal if something is broken there. Cheers, Daniel On 26.04.17 14:46, Pete Kelly wrote: Ah I see why it is confusing This setup maintains a Call-ID through an SBC downstream, so the INVITE's you see have the same Call-ID but they have a different fromtag/cseq, Wireshark shows them all as one call which is annoying when looking at the viewer! If you check the first call only between 252.70 and 252.75 you will see INVITE (frame 4), 200OK (frame 16) with lots of RR headers. The ACK generated by topos (frame 21) only contains 1 Route header, it should contain more so the request can hop through the proxy chain as shown in frame 16. I see the example from Sergey is working, but there is only 1 RR header in this example - as you can see from my example the topos module uses the first RR header but ignores the other 5. I have the DB dump and logfiles from this call too if useful. Pete On 26 April 2017 at 12:41, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: -- Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

Hi Daniel It's CSeq 1, fromtag A1 DB attached On 26 April 2017 at 15:03, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote:

>>>>> part of the record-routes >>>>> >>>>> Hope it helps >>>>> -- >>>>> Best regards, >>>>> Sergey Basov e-mail: sergey.v.basov(a)gmail.com >>>>> >>>>> >>>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <sergey.v.basov(a)gmail.com

>>>>>> - s_rr: [](0) >>>>>> >>>>>> 553 - seems a real correct size of the recordroute header and it >>>>>> differs from size with \0 at the end >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Sergey Basov e-mail: sergey.v.basov(a)gmail.com >>>>>> >>>>>> >>>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <sergey.v.basov(a)gmail.com

>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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.twitter.com/miconda -- www.linkedin.com/in/miconda >>>> Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com >>>> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com >>>>

Hi. No. Daniel does not merged fix yet. And he needs some time to backport it to 5.0 branch -- WBR Sergey Basov 8 мая 2017 г. 4:34 PM пользователь "Pete Kelly" &lt;pkelly(a)gmail.com&gt; написал: Is this fix in the nightly .deb build? > > I've just tested the latest and it's still broken > > On 8 May 2017 at 07:50, Sergey Basov &lt;sergey.v.basov(a)gmail.com&gt; wrote: > >> Hi, Daniel. >> >> I have created pool request >> >> https://github.com/kamailio/kamailio/pull/1124 >> -- >> Best regards, >> Sergey Basov e-mail: sergey.v.basov(a)gmail.com >> >> >> 2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla &lt;miconda(a)gmail.com >> >: >> > Try to make a pull request for it and if all ok it will be merged. >> > >> > Cheers, >> > Daniel >> > >> > >> > On 06.05.17 17:20, Sergey Basov wrote: >> >> I found issue cause. >> >> >> >> After I have changed line 792 of the file tps_msg.c >> >> from >> >> if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 0)<0) { >> >> >> >> to >> >> if(tps_reappend_route(msg, &stsd, &stsd.b_rr, 1)<0) { >> >> >> >> now route header are restores in from: >> >> >> >> Route: <sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4 >> Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 >> OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE >> AAgcAAAABAAAAAAAAAAAAAAAA> >> >> Route: <sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr> >> >> >> >> Now ACK are routed correctly. >> >> >> >> Seems that earlier, before fix b_rr store into DB, we does not see >> >> this issue, because only last route header was saved... >> >> But after fix, we have all route records so we nned to restore it >> into >> >> wright way. >> >> >> >> Now I have worked scheme with 3 kamailio in a row, on first of them >> >> enabled topos on other only topoh module. >> >> >> >> Daniel, I will send to you latest dump in separate e-mail. >> >> >> >> Thank you. >> >> >> >> -- >> >> Best regards, >> >> Sergey Basov e-mail: sergey.v.basov(a)gmail.com >> >> >> >> >> >> 2017-05-05 23:16 GMT+03:00 Sergey Basov &lt;sergey.v.basov(a)gmail.com&gt;om>: >> >>> I think it is because wrong order of Route: header after >> restoring... >> >>> >> >>> With topoh enabled I have: >> >>> >> >>> Route: <sip:10.56.42.37:5070;lr;ftag= >> IpXq-LwNvJF6WrkOcmZNf9WjmGjK5dUv;did=90c.1132;vsf=AAAAAAAAAA >> AAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=A >> AAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA> >> >>> Route: <sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr> >> >>> >> >>> But with topos enabled I have: >> >>> >> >>> Route: <sip:KITS1.MSS.LIFE.COM:5060;t >> ransport=UDP;lr>,<sip:10.56.42.37:5070;lr;ftag=EN0cvoXXCOgdG >> oO2zizq-WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2B >> mf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAA >> AAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA> >> >>> >> >>> And kamailio trying to send ACK to KITS1.MSS.LIFE.COM:5060 >> >>> >> >>> Can you fix it? Or I going in to wrong directuon? >> >>> >> >>> Thank you. >> >>> -- >> >>> Best regards, >> >>> Sergey Basov e-mail: sergey.v.basov(a)gmail.com >> >>> >> >>> >> >>> 2017-05-05 20:32 GMT+03:00 Sergey Basov &lt;sergey.v.basov(a)gmail.com >> >: >> >>>> Hi Daniel >> >>>> >> >>>> Semms now we have ankther problem... >> >>>> >> >>>> b_rr weites in db correctly. >> >>>> But when ack is sending from A side it try to send to B side to >> cantact ip, >> >>>> ignoring record-route headers... >> >>>> >> >>>> I will try to debug this. >> >>>> >> >>>> If you have any idea I can test it. >> >>>> >> >>>> Thank you. >> >>>> >> >>>> -- >> >>>> WBR >> >>>> Sergey Basov >> >>>> >> >>>> 28 апр. 2017 г. 7:25 PM пользователь "Sergey Basov" >> >>>> &lt;sergey.v.basov(a)gmail.com&gt; написал: >> >>>> >> >>>>> Hi Daniel. >> >>>>> >> >>>>> Seems all is ok now. >> >>>>> >> >>>>> I applyed your patch and add my additional debug string. >> >>>>> >> >>>>> Now result is: >> >>>>> >> >>>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >> >>>>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - >> b_rr: >> >>>>> >> >>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E >> k2ZS1uoLBVfSPhqYZXlvyga*>](84) >> >>>>> >> >>>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >> >>>>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - >> b_rr: >> >>>>> >> >>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E >> k2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.s >> RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX >> WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX >> nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX >> nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>](349) >> >>>>> >> >>>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >> >>>>> [tps_msg.c:464]: tps_pack_message(): sbasov compacted headers - >> b_rr: >> >>>>> >> >>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E >> k2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.s >> RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX >> WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX >> nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX >> nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<sip:10.5 >> 6.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d4 >> 1.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7d >> XNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAO >> AAAAAAAAAAAAAAAA>](556) >> >>>>> >> >>>>> Apr 28 19:15:52 csbc-uat /usr/sbin/kamailio[14177]: DEBUG: topos >> >>>>> [tps_msg.c:482]: tps_pack_message(): compacted headers - a_rr: >> [](0) - >> >>>>> b_rr: >> >>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E >> k2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.s >> RD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRX >> WQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsX >> nTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsX >> nTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<sip:10.5 >> 6.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d4 >> 1.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7d >> XNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAO >> AAAAAAAAAAAAAAAA>](556) >> >>>>> - s_rr: [](0) >> >>>>> >> >>>>> >> >>>>> Seems this issue is solved. >> >>>>> >> >>>>> Can you apply this patch to 5.0 branch? >> >>>>> Then may be Pete Kelly will install nightly build of the 5.0.1 >> and >> >>>>> confirm that issu is solved. >> >>>>> >> >>>>> I does not have such count of sbc for test ) >> >>>>> >> >>>>> Thank you Daniel. >> >>>>> -- >> >>>>> Best regards, >> >>>>> Sergey Basov e-mail: >> sergey.v.basov(a)gmail.com >> >>>>> >> >>>>> >> >>>>> 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla < >> miconda(a)gmail.com&gt;gt;: >> >>>>>> Hello, >> >>>>>> >> >>>>>> many thanks Sergey for troubleshooting, it saved a lot of time! >> >>>>>> Hopefully I caught the issue. Can you test with latest master >> branch and >> >>>>>> let me know if works? >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Daniel >> >>>>>> >> >>>>>> >> >>>>>> On 28.04.17 14:57, Sergey Basov wrote: >> >>>>>>> Some more debug >> >>>>>>> >> >>>>>>> after adding debug output after each iteration I got: >> >>>>>>> >> >>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: >> topos >> >>>>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers >> - b_rr: >> >>>>>>> >> >>>>>>> [<sip:127.0.0.8;line=sr-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E >> k2ZS1uoLBVfSPhqYZXlvyga*>](84) >> >>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: >> topos >> >>>>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers >> - b_rr: >> >>>>>>> >> >>>>>>> [<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZA >> eLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ. >> zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn >> TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXn >> TsFnTsXnTsXnTsXnTsXnTsXn>](348) >> >>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: >> topos >> >>>>>>> [tps_msg.c:457]: tps_pack_message(): sbasov compacted headers >> - b_rr: >> >>>>>>> >> >>>>>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB >> -4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h >> 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> AAAAQAAAAOAAAAAAAAAAAAAAAA>](554) >> >>>>>>> >> >>>>>>> Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: >> topos >> >>>>>>> [tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: >> [](0) - >> >>>>>>> b_rr: >> >>>>>>> [<sip:10.56.42.33:5090;lr;ftag=iOdvx4ub2iroSnVXNC4w784FIcbrB >> -4i;did=e9f.5f22;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h >> 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> AAAAQAAAAOAAAAAAAAAAAAAAAA>](554) >> >>>>>>> - s_rr: [](0) >> >>>>>>> >> >>>>>>> So size are computed correctly, but part of record-routes >> >>>>>>> disappears.... And we can see correct size of the record but >> only last >> >>>>>>> part of the record-routes >> >>>>>>> >> >>>>>>> Hope it helps >> >>>>>>> -- >> >>>>>>> Best regards, >> >>>>>>> Sergey Basov e-mail: >> sergey.v.basov(a)gmail.com >> >>>>>>> >> >>>>>>> >> >>>>>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov < >> sergey.v.basov(a)gmail.com&gt;gt;: >> >>>>>>>> One more detail >> >>>>>>>> >> >>>>>>>> When debug=3 I see in logs (look at size of record and it >> contents) >> >>>>>>>> >> >>>>>>>> Apr 28 14:16:44 csbc-uat /usr/sbin/kamailio[13287]: DEBUG: >> topos >> >>>>>>>> [tps_msg.c:473]: tps_pack_message(): compacted headers - >> a_rr: [](0) - >> >>>>>>>> b_rr: [](0) - s_rr: >> >>>>>>>> >> >>>>>>>> [<sip:10.56.42.33;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOf >> IVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX >> 14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9B >> RxjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,<sip:212.58.160.253:506 >> 1;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIV >> Tn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14 >> CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR >> xjYGAUeXl/dRU2PChyPXBob25l;nat=yes>](453) >> >>>>>>>> >> >>>>>>>> 453 - is a real size of shown header >> >>>>>>>> >> >>>>>>>> s_rr parses normal, but b_rr >> >>>>>>>> >> >>>>>>>> Apr 28 14:16:48 csbc-uat /usr/sbin/kamailio[13273]: DEBUG: >> topos >> >>>>>>>> [tps_msg.c:473]: tps_pack_message(): compacted headers - >> a_rr: [](0) - >> >>>>>>>> b_rr: >> >>>>>>>> [<sip:10.56.42.33:5090;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfI >> VTn;did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 >> OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> AAAQAAAAOAAAAAAAAAAAAAAAA>](553) >> >>>>>>>> - s_rr: [](0) >> >>>>>>>> >> >>>>>>>> 553 - seems a real correct size of the recordroute header and >> it >> >>>>>>>> differs from size with \0 at the end >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Best regards, >> >>>>>>>> Sergey Basov e-mail: >> sergey.v.basov(a)gmail.com >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov < >> sergey.v.basov(a)gmail.com&gt;gt;: >> >>>>>>>>> Hi All. >> >>>>>>>>> >> >>>>>>>>> I just try to pass call throught 3 kamailio. >> >>>>>>>>> I got result like yours >> >>>>>>>>> >> >>>>>>>>> If you need testers for patch - I am ready ) >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> Best regards, >> >>>>>>>>> Sergey Basov e-mail: >> sergey.v.basov(a)gmail.com >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >> >>>>>>>>> &lt;miconda(a)gmail.com&gt;om>: >> >>>>>>>>>> There seems to be an issue saving the record-route list for >> b-side >> >>>>>>>>>> in >> >>>>>>>>>> topos_d table -- first two are saved but then there are >> only 0 >> >>>>>>>>>> characters >> >>>>>>>>>> instead of the rest of record routes: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> '<sip:192.168.252.75;r2=on;lr= >> on;ftag=A1;did=072.87c;rtpi=1;nat=no;rtpi=1>\0\0\0\0\0\0\0\0 >> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 >> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 >> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 >> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 >> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 >> \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0' >> >>>>>>>>>> >> >>>>>>>>>> I will have to dig a bit into the code. >> >>>>>>>>>> >> >>>>>>>>>> Cheers, Daniel >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On 27.04.17 14:30, Pete Kelly wrote: >> >>>>>>>>>> >> >>>>>>>>>> Yes no problem. I wanted to come but the life schedule >> would not >> >>>>>>>>>> allow it >> >>>>>>>>>> this time. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On 27 April 2017 at 13:11, Daniel-Constantin Mierla >> >>>>>>>>>> &lt;miconda(a)gmail.com&gt; >> >>>>>>>>>> wrote: >> >>>>>>>>>>> Hello, >> >>>>>>>>>>> >> >>>>>>>>>>> time, I need more time :-) ... with Kamailio World >> Conference >> >>>>>>>>>>> around the >> >>>>>>>>>>> corner, I am caught in a lot of admin tasks... >> >>>>>>>>>>> >> >>>>>>>>>>> Daniel >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On 27.04.17 13:11, Pete Kelly wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Hi Daniel >> >>>>>>>>>>> >> >>>>>>>>>>> Is there anything else you need on this? >> >>>>>>>>>>> >> >>>>>>>>>>> On 26 April 2017 at 15:06, Pete Kelly &lt;pkelly(a)gmail.com&gt; >> wrote: >> >>>>>>>>>>>> Hi Daniel >> >>>>>>>>>>>> >> >>>>>>>>>>>> It's CSeq 1, fromtag A1 >> >>>>>>>>>>>> >> >>>>>>>>>>>> DB attached >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >> >>>>>>>>>>>> &lt;miconda(a)gmail.com&gt; >> >>>>>>>>>>>> wrote: >> >>>>>>>>>>>>> Can you paste here the from tag or cseq for the dialog >> you are >> >>>>>>>>>>>>> referring >> >>>>>>>>>>>>> to? Because the number of frames are not matching my >> pcap viewer. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Send also the db dump, they should reveal if something >> is broken >> >>>>>>>>>>>>> there. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Cheers, >> >>>>>>>>>>>>> Daniel >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On 26.04.17 14:46, Pete Kelly wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Ah I see why it is confusing >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> This setup maintains a Call-ID through an SBC >> downstream, so the >> >>>>>>>>>>>>> INVITE's you see have the same Call-ID but they have a >> different >> >>>>>>>>>>>>> fromtag/cseq, Wireshark shows them all as one call which >> is >> >>>>>>>>>>>>> annoying when >> >>>>>>>>>>>>> looking at the viewer! >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> If you check the first call only between 252.70 and >> 252.75 you >> >>>>>>>>>>>>> will see >> >>>>>>>>>>>>> INVITE (frame 4), 200OK (frame 16) with lots of RR >> headers. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> The ACK generated by topos (frame 21) only contains 1 >> Route >> >>>>>>>>>>>>> header, it >> >>>>>>>>>>>>> should contain more so the request can hop through the >> proxy >> >>>>>>>>>>>>> chain as shown >> >>>>>>>>>>>>> in frame 16. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I see the example from Sergey is working, but there is >> only 1 RR >> >>>>>>>>>>>>> header >> >>>>>>>>>>>>> in this example - as you can see from my example the >> topos module >> >>>>>>>>>>>>> uses the >> >>>>>>>>>>>>> first RR header but ignores the other 5. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I have the DB dump and logfiles from this call too if >> useful. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Pete >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On 26 April 2017 at 12:41, Daniel-Constantin Mierla >> >>>>>>>>>>>>> &lt;miconda(a)gmail.com&gt; >> >>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>> As I could notice upon a quick look, there seems to be >> two calls >> >>>>>>>>>>>>>> -- two >> >>>>>>>>>>>>>> INVITE requests having same call id but different cseq. >> Can you >> >>>>>>>>>>>>>> confirm >> >>>>>>>>>>>>>> this is the case? Because the capture doesn't seem to >> have all >> >>>>>>>>>>>>>> the >> >>>>>>>>>>>>>> incoming/outgoing messages, some are missing. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Cheers, >> >>>>>>>>>>>>>> Daniel >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> On 26.04.17 12:59, Sergey Basov wrote: >> >>>>>>>>>>>>>>> You give to us very hard callflow... >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Without any pauses between responces.. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Some requests go through 127.0.0.1... But responces >> from >> >>>>>>>>>>>>>>> 127.0.0.1 >> >>>>>>>>>>>>>>> not present. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> There are peers from which invites not present in >> dump. I can >> >>>>>>>>>>>>>>> not see >> >>>>>>>>>>>>>>> ful path of the initial Invite, but there is responses. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> I will send dump in next email directly. >> >>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>> Best regards, >> >>>>>>>>>>>>>>> Sergey Basov e-mail: >> >>>>>>>>>>>>>>> sergey.v.basov(a)gmail.com >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly < >> pkelly(a)gmail.com&gt;gt;: >> >>>>>>>>>>>>>>>> Attached is the pcap from latest nightly. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> As you can see (frame 21) the ACK is incorrect, I >> believe it >> >>>>>>>>>>>>>>>> should >> >>>>>>>>>>>>>>>> specify >> >>>>>>>>>>>>>>>> all the hops from the 200OK (frame 16) so that the >> hop by hop >> >>>>>>>>>>>>>>>> ACK >> >>>>>>>>>>>>>>>> can be >> >>>>>>>>>>>>>>>> routed via the proxy chain. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> topoh module works fine. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Pete >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> On 26 April 2017 at 05:18, Sergey Basov >> >>>>>>>>>>>>>>>> &lt;sergey.v.basov(a)gmail.com&gt; >> >>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>> I dont know how nightly builds are done. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Just try with latest 5.0.1 nightly and send new dump. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> As I understud topos module done to remove >> record-route >> >>>>>>>>>>>>>>>>> headers to >> >>>>>>>>>>>>>>>>> hide >> >>>>>>>>>>>>>>>>> topology... Am I wright, Daniel? >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> And try to disable topos module and enable topoh >> module. Will >> >>>>>>>>>>>>>>>>> it >> >>>>>>>>>>>>>>>>> all work >> >>>>>>>>>>>>>>>>> as you expecrs? >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>> WBR >> >>>>>>>>>>>>>>>>> Sergey Basov >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> 25 апр. 2017 г. 11:31 PM пользователь "Pete Kelly" >> >>>>>>>>>>>>>>>>> &lt;pkelly(a)gmail.com&gt; >> >>>>>>>>>>>>>>>>> написал: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> I have tried with 5.0.1 from today (25th April). >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> Are you saying build for 26th will have some fixes? >> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> On 25 April 2017 at 18:59, Sergey Basov >> >>>>>>>>>>>>>>>>>> &lt;sergey.v.basov(a)gmail.com&gt; >> >>>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>>>> Actualy latest fixes to 180/183/200, ACK and >> memory leak >> >>>>>>>>>>>>>>>>>>> was >> >>>>>>>>>>>>>>>>>>> pushed to >> >>>>>>>>>>>>>>>>>>> 5.0 and master branch. >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> So, please try with latest 5.0.1 nightly. >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>>>> WBR >> >>>>>>>>>>>>>>>>>>> Sergey Basov >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> 25 апр. 2017 г. 8:55 PM пользователь "Pete Kelly" >> >>>>>>>>>>>>>>>>>>> &lt;pkelly(a)gmail.com&gt; >> >>>>>>>>>>>>>>>>>>> написал: >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> Call is with sipp but first goes through another >> SBC to >> >>>>>>>>>>>>>>>>>>>> clean up >> >>>>>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>>>>> SIP (in case of problems with sipp via headers >> etc). >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> The traces I've done are actually with 4.4. >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> Will they be OK or would you prefer 5.0.1? The >> problem is >> >>>>>>>>>>>>>>>>>>>> exactly the >> >>>>>>>>>>>>>>>>>>>> same on both. >> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> On 25 April 2017 at 16:25, Sergey Basov >> >>>>>>>>>>>>>>>>>>>> &lt;sergey.v.basov(a)gmail.com&gt; >> >>>>>>>>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>>>>>>> Hi. >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> Can you send dump of the call with kamailio 5.0.1 >> >>>>>>>>>>>>>>>>>>>>> nightly? >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> And does you make call using sipp? >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>>>>>> WBR >> >>>>>>>>>>>>>>>>>>>>> Sergey Basov >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> 25 апр. 2017 г. 5:57 PM пользователь "Pete Kelly" >> >>>>>>>>>>>>>>>>>>>>> &lt;pkelly(a)gmail.com&gt; >> >>>>>>>>>>>>>>>>>>>>> написал: >> >>>>>>>>>>>>>>>>>>>>>> Looks like from last night: >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> 5.0.1+0~20170425013247.36+trusty >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> On 25 April 2017 at 15:42, Daniel-Constantin >> Mierla >> >>>>>>>>>>>>>>>>>>>>>> &lt;miconda(a)gmail.com&gt; wrote: >> >>>>>>>>>>>>>>>>>>>>>>> Hello, >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> to be sure, it is 5.0.1 build from last night >> or quite >> >>>>>>>>>>>>>>>>>>>>>>> recent? There >> >>>>>>>>>>>>>>>>>>>>>>> were some fixes in the past days to topos >> module. >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> Cheers, >> >>>>>>>>>>>>>>>>>>>>>>> Daniel >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> On 25.04.17 15:59, Pete Kelly wrote: >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> Hi Daniel >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> Sorry for the delayed response to this, the >> ACK is for >> >>>>>>>>>>>>>>>>>>>>>>> a >> >>>>>>>>>>>>>>>>>>>>>>> 200OK yes >> >>>>>>>>>>>>>>>>>>>>>>> and the problem still persists in latest 4.4 >> and the >> >>>>>>>>>>>>>>>>>>>>>>> 5.0.1 >> >>>>>>>>>>>>>>>>>>>>>>> nightly build. >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> I have all DB entries/kam logs/pcap files. >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> If you check the attached pcap, 192.168.70.70 >> and >> >>>>>>>>>>>>>>>>>>>>>>> 192.168.252.70 are >> >>>>>>>>>>>>>>>>>>>>>>> the same instance of Kamailio, it is being >> used to >> >>>>>>>>>>>>>>>>>>>>>>> bridge the >> >>>>>>>>>>>>>>>>>>>>>>> 2 networks. >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> Frame 34 shows the 200OK with lots of >> Record-Route etc, >> >>>>>>>>>>>>>>>>>>>>>>> and >> >>>>>>>>>>>>>>>>>>>>>>> frame 35 >> >>>>>>>>>>>>>>>>>>>>>>> shows topos in action. >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> However the ACK that is relayed in Frame 38 >> seems to be >> >>>>>>>>>>>>>>>>>>>>>>> missing all >> >>>>>>>>>>>>>>>>>>>>>>> the Route information that was supplied in the >> 200OK, >> >>>>>>>>>>>>>>>>>>>>>>> this >> >>>>>>>>>>>>>>>>>>>>>>> causes the ACK to >> >>>>>>>>>>>>>>>>>>>>>>> be relayed directly to the Contact, breaking >> the proxy >> >>>>>>>>>>>>>>>>>>>>>>> chain. >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> Pete >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> On 22 February 2017 at 18:31, >> Daniel-Constantin Mierla >> >>>>>>>>>>>>>>>>>>>>>>> &lt;miconda(a)gmail.com&gt; wrote: >> >>>>>>>>>>>>>>>>>>>>>>>> Hello, >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> is the ACK for 200ok? Or an ack for a negative >> >>>>>>>>>>>>>>>>>>>>>>>> response? >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> Can you get a pcap for such situation with all >> >>>>>>>>>>>>>>>>>>>>>>>> messages >> >>>>>>>>>>>>>>>>>>>>>>>> related to >> >>>>>>>>>>>>>>>>>>>>>>>> the call? >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> Cheers, >> >>>>>>>>>>>>>>>>>>>>>>>> Daniel >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> On 22/02/2017 17:20, Pete Kelly wrote: >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> Hi >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> I am using the topos module when bridging 2 >> networks >> >>>>>>>>>>>>>>>>>>>>>>>> with >> >>>>>>>>>>>>>>>>>>>>>>>> Kamailio. >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> The INVITE/200OK part of the transaction is >> working >> >>>>>>>>>>>>>>>>>>>>>>>> fine >> >>>>>>>>>>>>>>>>>>>>>>>> (i.e. the >> >>>>>>>>>>>>>>>>>>>>>>>> Contact on both sides matches correctly the >> >>>>>>>>>>>>>>>>>>>>>>>> corresponding >> >>>>>>>>>>>>>>>>>>>>>>>> network). >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> However when the ACK is sent into Kamailio, >> instead of >> >>>>>>>>>>>>>>>>>>>>>>>> realising >> >>>>>>>>>>>>>>>>>>>>>>>> the next hop is myself and skipping it, >> Kamailio is >> >>>>>>>>>>>>>>>>>>>>>>>> sending >> >>>>>>>>>>>>>>>>>>>>>>>> the ACK directly >> >>>>>>>>>>>>>>>>>>>>>>>> to itself as a packet, causing the call setup >> to >> >>>>>>>>>>>>>>>>>>>>>>>> break. >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> Does anyone have any advice for this >> situation? >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> ______________________________ >> _________________ >> >>>>>>>>>>>>>>>>>>>>>>>> SIP Express Router (SER) and Kamailio >> (OpenSER) - >> >>>>>>>>>>>>>>>>>>>>>>>> sr-users >> >>>>>>>>>>>>>>>>>>>>>>>> mailing >> >>>>>>>>>>>>>>>>>>>>>>>> list >> >>>>>>>>>>>>>>>>>>>>>>>> sr-users(a)lists.sip-router.org >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> http://lists.sip-router.org/cg >> i-bin/mailman/listinfo/sr-users >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>>>>>>>>> Daniel-Constantin Mierla >> >>>>>>>>>>>>>>>>>>>>>>>> www.twitter.com/miconda -- >> www.linkedin.com/in/miconda >> >>>>>>>>>>>>>>>>>>>>>>>> Kamailio Advanced Training - Mar 6-8 (Europe) >> and Mar >> >>>>>>>>>>>>>>>>>>>>>>>> 20-22 >> >>>>>>>>>>>>>>>>>>>>>>>> (USA) - >> >>>>>>>>>>>>>>>>>>>>>>>> www.asipto.com >> >>>>>>>>>>>>>>>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 - >> >>>>>>>>>>>>>>>>>>>>>>>> www.kamailioworld.com >> >>>>>>>>>>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>>>>>>>>>>> Daniel-Constantin Mierla >> >>>>>>>>>>>>>>>>>>>>>>> www.twitter.com/miconda -- >> www.linkedin.com/in/miconda >> >>>>>>>>>>>>>>>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) - >> >>>>>>>>>>>>>>>>>>>>>>> www.asipto.com >> >>>>>>>>>>>>>>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 - >> >>>>>>>>>>>>>>>>>>>>>>> www.kamailioworld.com >> >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>>>>>>>>>>>> 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.twitter.com/miconda -- www.linkedin.com/in/miconda >> >>>>>>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) - >> www.asipto.com >> >>>>>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 - >> >>>>>>>>>>>>>> www.kamailioworld.com >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> -- >> >>>>>>>>>>>>> Daniel-Constantin Mierla >> >>>>>>>>>>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda >> >>>>>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) - >> www.asipto.com >> >>>>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 - >> >>>>>>>>>>>>> www.kamailioworld.com >> >>>>>>>>>>> -- >> >>>>>>>>>>> Daniel-Constantin Mierla >> >>>>>>>>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda >> >>>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) - >> www.asipto.com >> >>>>>>>>>>> Kamailio World Conference - May 8-10, 2017 - >> www.kamailioworld.com >> >>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> Daniel-Constantin Mierla >> >>>>>>>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda >> >>>>>>>>>> Kamailio Advanced Training - May 22-24 (USA) - >> www.asipto.com >> >>>>>>>>>> Kamailio World Conference - May 8-10, 2017 - >> www.kamailioworld.com >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> 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.twitter.com/miconda -- www.linkedin.com/in/miconda >> >>>>>> Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com >> >>>>>> Kamailio World Conference - May 8-10, 2017 - >> www.kamailioworld.com >> >>>>>> >> > >> > -- >> > Daniel-Constantin Mierla >> > www.twitter.com/miconda -- www.linkedin.com/in/miconda >> > Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com >> > Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com >> > >> > >