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: sergey.v.ba...@gmail.com 2017-04-28 15:37 GMT+03:00 Sergey Basov <sergey.v.ba...@gmail.com>: > 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: sergey.v.ba...@gmail.com > > > 2017-04-28 14:46 GMT+03:00 Sergey Basov <sergey.v.ba...@gmail.com>: >> 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.ba...@gmail.com >> >> >> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla <mico...@gmail.com>: >>> 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 <mico...@gmail.com> >>> 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 <pke...@gmail.com> wrote: >>>>> >>>>> Hi Daniel >>>>> >>>>> It's CSeq 1, fromtag A1 >>>>> >>>>> DB attached >>>>> >>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla <mico...@gmail.com> >>>>> 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 <mico...@gmail.com> >>>>>> 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.ba...@gmail.com >>>>>>> > >>>>>>> > >>>>>>> > 2017-04-26 11:01 GMT+03:00 Pete Kelly <pke...@gmail.com>: >>>>>>> >> 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 <sergey.v.ba...@gmail.com> >>>>>>> >> 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" >>>>>>> >>> <pke...@gmail.com> >>>>>>> >>> написал: >>>>>>> >>> >>>>>>> >>>> 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 <sergey.v.ba...@gmail.com> >>>>>>> >>>> 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" >>>>>>> >>>>> <pke...@gmail.com> >>>>>>> >>>>> написал: >>>>>>> >>>>> >>>>>>> >>>>>> 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 >>>>>>> >>>>>> <sergey.v.ba...@gmail.com> >>>>>>> >>>>>> 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" >>>>>>> >>>>>>> <pke...@gmail.com> >>>>>>> >>>>>>> написал: >>>>>>> >>>>>>>> Looks like from last night: >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> 5.0.1+0~20170425013247.36+trusty >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> On 25 April 2017 at 15:42, Daniel-Constantin Mierla >>>>>>> >>>>>>>> <mico...@gmail.com> 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 >>>>>>> >>>>>>>>> <mico...@gmail.com> 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-us...@lists.sip-router.org >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> 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 >>>>>>> >>>>>>>> sr-users@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@lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users