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" <[email protected]> написал: > 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 <[email protected]> wrote: > >> Hi, Daniel. >> >> I have created pool request >> >> https://github.com/kamailio/kamailio/pull/1124 >> -- >> Best regards, >> Sergey Basov e-mail: [email protected] >> >> >> 2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla <[email protected]>: >> > 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: [email protected] >> >> >> >> >> >> 2017-05-05 23:16 GMT+03:00 Sergey Basov <[email protected]>: >> >>> 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-LwNvJF6WrkOcmZNf9WjmGjK5d >> Uv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9 >> OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE >> AAgcAAAABAAAAAAAAAAAAAAAA> >> >>> Route: <sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr> >> >>> >> >>> But with topos enabled I have: >> >>> >> >>> Route: <sip:KITS1.MSS.LIFE.COM:5060;transport=UDP;lr>,<sip:10.56.42 >> .37:5070;lr;ftag=EN0cvoXXCOgdGoO2zizq-WNmE4Enf4Nt;did=434. >> 5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXN >> lcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAA >> AAAAAAAAAAAAAA> >> >>> >> >>> 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: [email protected] >> >>> >> >>> >> >>> 2017-05-05 20:32 GMT+03:00 Sergey Basov <[email protected]>: >> >>>> 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" >> >>>> <[email protected]> написал: >> >>>> >> >>>>> 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.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYd >> dReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTs >> XnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTs >> XnTsXnTsXnTsXnTsXne7YnTuP.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.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYd >> dReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTs >> XnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTs >> XnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,< >> sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRU >> Y;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9O >> jUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> AAQAAAAOAAAAAAAAAAAAAAAA>](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.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYd >> dReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTs >> XnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTs >> XnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,< >> sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRU >> Y;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9O >> jUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA >> AAQAAAAOAAAAAAAAAAAAAAAA>](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: [email protected] >> >>>>> >> >>>>> >> >>>>> 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla < >> [email protected]>: >> >>>>>> 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: [email protected] >> >>>>>>> >> >>>>>>> >> >>>>>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <[email protected] >> >: >> >>>>>>>> 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=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRxjYGAUeXl/ >> dRU2PChyPXBob25l;nat=yes>,<sip:212.58.160.253:5061; >> transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIV >> Tn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14 >> CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRx >> jYGAUeXl/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: >> [email protected] >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov < >> [email protected]>: >> >>>>>>>>> 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: >> [email protected] >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla >> >>>>>>>>> <[email protected]>: >> >>>>>>>>>> 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 >> >>>>>>>>>> <[email protected]> >> >>>>>>>>>> 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 <[email protected]> >> wrote: >> >>>>>>>>>>>> Hi Daniel >> >>>>>>>>>>>> >> >>>>>>>>>>>> It's CSeq 1, fromtag A1 >> >>>>>>>>>>>> >> >>>>>>>>>>>> DB attached >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla >> >>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>> 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 >> >>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>> 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: >> >>>>>>>>>>>>>>> [email protected] >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly <[email protected]>: >> >>>>>>>>>>>>>>>> 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 >> >>>>>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>>>>> 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" >> >>>>>>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>>>>>> написал: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> 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 >> >>>>>>>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>>>>>>> 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" >> >>>>>>>>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>>>>>>>> написал: >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> 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 >> >>>>>>>>>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>>>>>>>>> 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" >> >>>>>>>>>>>>>>>>>>>>> <[email protected]> >> >>>>>>>>>>>>>>>>>>>>> написал: >> >>>>>>>>>>>>>>>>>>>>>> Looks like from last night: >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> 5.0.1+0~20170425013247.36+trusty >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> On 25 April 2017 at 15:42, Daniel-Constantin Mierla >> >>>>>>>>>>>>>>>>>>>>>> <[email protected]> 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 >> >>>>>>>>>>>>>>>>>>>>>>> <[email protected]> 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 >> >>>>>>>>>>>>>>>>>>>>>>>> [email protected] >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> 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 >> >>>>>>>>>>>>>>>>>>>>>> [email protected] >> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> 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 >> >>>>>>>>>> [email protected] >> >>>>>>>>>> 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 >> > >> > >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
