[SR-Users] topos module - possible bug
Sergey Basov
sergey.v.basov at gmail.com
Mon May 8 15:37:40 CEST 2017
Hi.
No. Daniel does not merged fix yet.
And he needs some time to backport it to 5.0 branch
--
WBR
Sergey Basov
8 мая 2017 г. 4:34 PM пользователь "Pete Kelly" <pkelly at gmail.com> написал:
> Is this fix in the nightly .deb build?
>
> I've just tested the latest and it's still broken
>
> On 8 May 2017 at 07:50, Sergey Basov <sergey.v.basov at gmail.com> wrote:
>
>> 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-WNmE4Enf4
>> Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9
>> OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE
>> AAgcAAAABAAAAAAAAAAAAAAAA>
>> >> 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-LwNvJF6WrkOcmZNf9WjmGjK5d
>> Uv;did=90c.1132;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9
>> OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgE
>> AAgcAAAABAAAAAAAAAAAAAAAA>
>> >>> 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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9OjUwNjA7dXN
>> lcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEAAgcAAAABAA
>> AAAAAAAAAAAAAA>
>> >>>
>> >>> 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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>> k2ZS1uoLBVfSPhqYZXlvyga*>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>> k2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.
>> dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYd
>> dReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTs
>> XnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTs
>> XnTsXnTsXnTsXnTsXne7YnTuP.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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>> k2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.
>> dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYd
>> dReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTs
>> XnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTs
>> XnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<
>> sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRU
>> Y;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9O
>> jUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>> AAQAAAAOAAAAAAAAAAAAAAAA>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>> k2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-BRwEk.
>> dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXUYbGjQdPrTMqbYd
>> dReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXnTs
>> XnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXnTs
>> XnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,<
>> sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRU
>> Y;did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9O
>> jUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>> AAQAAAAOAAAAAAAAAAAAAAAA>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxppCqzh1E
>> k2ZS1uoLBVfSPhqYZXlvyga*>](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.sEGLlvygavebZA
>> eLq9pRZROhZq1.F9BJfpywe1pMz7PLB8GdeF1RFST377QpcMQuTfepwJDJZ.
>> zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn
>> TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.TsXn
>> TsFnTsXnTsXnTsXnTsXnTsXn>](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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h
>> 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>> AAAAQAAAAOAAAAAAAAAAAAAAAA>](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=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h
>> 9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>> AAAAQAAAAOAAAAAAAAAAAAAAAA>](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.1TlqHP7frDwZWwhcyKAcOf
>> IVTn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX
>> 14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRxjYGAUeXl/
>> dRU2PChyPXBob25l;nat=yes>,<sip:212.58.160.253:5061;
>> transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIV
>> Tn;did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3Rnd3MebX14
>> CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BRx
>> jYGAUeXl/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.1TlqHP7frDwZWwhcyKAcOfI
>> VTn;did=a4b.6ec;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HGJ6cX8bc3h9
>> OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
>> AAAQAAAAOAAAAAAAAAAAAAAAA>](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/cg
>> i-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
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170508/b84dba9e/attachment.html>
More information about the sr-users
mailing list