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