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 _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
