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: sergey.v.basov@gmail.com
2017-04-28 15:37 GMT+03:00 Sergey Basov sergey.v.basov@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.basov@gmail.com
2017-04-28 14:46 GMT+03:00 Sergey Basov sergey.v.basov@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.basov@gmail.com
2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla miconda@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 miconda@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 pkelly@gmail.com wrote:
Hi Daniel
It's CSeq 1, fromtag A1
DB attached
On 26 April 2017 at 15:03, Daniel-Constantin Mierla miconda@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 miconda@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.basov@gmail.com >>> >>> >>> 2017-04-26 11:01 GMT+03:00 Pete Kelly pkelly@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.basov@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" >>>>> pkelly@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.basov@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" >>>>>>> pkelly@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.basov@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" >>>>>>>>> pkelly@gmail.com >>>>>>>>> написал: >>>>>>>>>> Looks like from last night: >>>>>>>>>> >>>>>>>>>> 5.0.1+0~20170425013247.36+trusty >>>>>>>>>> >>>>>>>>>> On 25 April 2017 at 15:42, Daniel-Constantin Mierla >>>>>>>>>> miconda@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 >>>>>>>>>>> miconda@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-users@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