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-WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA> >> 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-LwNvJF6WrkOcmZNf9WjmGjK5dUv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA> >>> 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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAAAAAAAAAAAAAAAA> >>> >>> 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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](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.sEGLlvygavebZAeLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>](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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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.1TlqHP7frDwZWwhcyKAcOfIVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRxjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,<sip:212.58.160.253:5061;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRxjYGAUeXl/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.1TlqHP7frDwZWwhcyKAcOfIVTn;did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAOAAAAAAAAAAAAAAAA>](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/cgi-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
