[SR-Users] topos module - possible bug
Pete Kelly
pkelly at gmail.com
Mon May 8 15:34:13 CEST 2017
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-
> WNmE4Enf4Nt;did=434.5ce1;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
> J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAg
> EAAgcAAAABAAAAAAAAAAAAAAAA>
> >> 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=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
> J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAg
> EAAgcAAAABAAAAAAAAAAAAAAAA>
> >>> 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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
> Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
> Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-
> BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU
> YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn
> TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn
> TsXnTsXnTsXnTsXnTsXne7YnTuP.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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
> Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-
> BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU
> YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn
> TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn
> TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,
> <sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;
> did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
> J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAQAAAAOAAAAAAAAAAAAAAAA>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
> Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>,<sip:127.0.0.8;line=sr-
> BRwEk.dED.sRD.TSD.z2k.sEGLlvygavebZAeLqVDJ7cZRoXPrXU
> YbGjQdPrTMqbYddReRXWQs9xWXFYupcMQuTfehTjD.lRkhavPbGJxsXnTsXnTsXnTsXnTsXn
> TsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsdvPbG7xsXnTsXnTsXnTsXnTsXn
> TsXnTsXnTsXnTsXnTsXne7YnTuP.TsXnTsFnTsXnTsXnTsXnTsXnTsXn>,
> <sip:10.56.42.33:5090;lr;ftag=F.m-GnEuqBVsqhGWBMgTA6gaRiJOHRUY;
> did=d41.3811;vsf=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
> J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAQAAAAOAAAAAAAAAAAAAAAA>](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-BRwEkMcFYXzjDMqpsSozWseXDMGxpp
> Cqzh1Ek2ZS1uoLBVfSPhqYZXlvyga*>](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.
> zhdvPbGJxsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXn
> TsdvPbG7xsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXnTsXne7YnTuP.
> 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=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
> J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;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=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
> J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;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.1TlqHP7frDwZWwhcyKAcOfIVTn;
> did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3
> Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR
> xjYGAUeXl/dRU2PChyPXBob25l;nat=yes>,<sip:212.58.160.253:
> 5061;transport=tls;r2=on;lr;ftag=ed1qg.1TlqHP7frDwZWwhcyKAcOfIVTn;
> did=a4b.fc01;vsf=AAAAAAoLAQ4DAA4DAHlnYg5heGJnG3
> Rnd3MebX14CTUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAMOAwEABwcEAwd3AnBlfGJ9BR
> xjYGAUeXl/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=AAAAAAAAAAAAAAAAAABlY2Bmf359HG
> J6cX8bc3h9OjUwNjA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> AAAAQAAAAOAAAAAAAAAAAAAAAA>](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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170508/88d4b5b2/attachment.html>
More information about the sr-users
mailing list