[SR-Users] topos module - possible bug
Sergey Basov
sergey.v.basov at gmail.com
Mon May 8 08:50:03 CEST 2017
Hi, Daniel.
I have created pool request
https://github.com/kamailio/kamailio/pull/1124
--
Best regards,
Sergey Basov e-mail: sergey.v.basov at gmail.com
2017-05-08 8:44 GMT+03:00 Daniel-Constantin Mierla <miconda at gmail.com>:
> 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: sergey.v.basov at gmail.com
>>
>>
>> 2017-05-05 23:16 GMT+03:00 Sergey Basov <sergey.v.basov at gmail.com>:
>>> 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: sergey.v.basov at gmail.com
>>>
>>>
>>> 2017-05-05 20:32 GMT+03:00 Sergey Basov <sergey.v.basov at gmail.com>:
>>>> 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"
>>>> <sergey.v.basov at gmail.com> написал:
>>>>
>>>>> 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: sergey.v.basov at gmail.com
>>>>>
>>>>>
>>>>> 2017-04-28 17:14 GMT+03:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>>>>> 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 at gmail.com
>>>>>>>
>>>>>>>
>>>>>>> 2017-04-28 15:37 GMT+03:00 Sergey Basov <sergey.v.basov at 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 at gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-04-28 14:46 GMT+03:00 Sergey Basov <sergey.v.basov at 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 at gmail.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla
>>>>>>>>> <miconda at 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 at 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 at gmail.com> wrote:
>>>>>>>>>>>> Hi Daniel
>>>>>>>>>>>>
>>>>>>>>>>>> It's CSeq 1, fromtag A1
>>>>>>>>>>>>
>>>>>>>>>>>> DB attached
>>>>>>>>>>>>
>>>>>>>>>>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla
>>>>>>>>>>>> <miconda at 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 at 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 at gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2017-04-26 11:01 GMT+03:00 Pete Kelly <pkelly at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
>
More information about the sr-users
mailing list